KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)

commit fda4e2e85589191b123d31cdc21fd33ee70f50fd upstream.

In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
potential to corrupt kernel memory if userspace provides an address that
is at the end of a page.  This patches concerts those functions to use
kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
vapic_address specified by userspace during ioctl processing and returns
an error to userspace if the address is not a valid GPA.

This is generally not guest triggerable, because the required write is
done by firmware that runs before the guest.  Also, it only affects AMD
processors and oldish Intel that do not have the FlexPriority feature
(unless you disable FlexPriority, of course; then newer processors are
also affected).

Fixes: b93463aa59d6 ('KVM: Accelerated apic support')

Reported-by: Andrew Honig <ahonig@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ lizf: backported to 3.4: based on Paolo's backport hints for <3.10 ]
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: comedi: 8255_pci: fix for newer PCI-DIO48H

commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream.

At some point, Measurement Computing / ComputerBoards redesigned the
PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip.
This meant they had to put their hardware registers in the PCI BAR 2
region instead of PCI BAR 1.  Unfortunately, they kept the same PCI
device ID for the new design.  This means the driver recognizes the
newer cards, but doesn't work (and is likely to screw up the local
configuration registers of the PLX chip) because it's using the wrong
region.

Since  the PCI subvendor and subdevice IDs were both zero on the old
design, but are the same as the vendor and device on the new design, we
can tell the old design and new design apart easily enough.  Split the
existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new
entries, referenced by different entries in the PCI device ID table
`pci_8255_pci_table[]`.  Use the same board name for both entries.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h

commit bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6 upstream.

On AMD family 10h we see following error messages while waking up from
S3 for all non-boot CPUs leading to a failed IBS initialization:

 Enabling non-boot CPUs ...
 smpboot: Booting Node 0 Processor 1 APIC 0x1
 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu
 perf: IBS APIC setup failed on cpu #1
 process: Switch to broadcast mode on CPU1
 CPU1 is up
 ...
 ACPI: Waking up from system sleep state S3

Reason for this is that during suspend the LVT offset for the IBS
vector gets lost and needs to be reinialized while resuming.

The offset is read from the IBSCTL msr. On family 10h the offset needs
to be 1 as offset 0 is used for the MCE threshold interrupt, but
firmware assings it for IBS to 0 too. The kernel needs to reprogram
the vector. The msr is a readonly node msr, but a new value can be
written via pci config space access. The reinitialization is
implemented for family 10h in setup_ibs_ctl() which is forced during
IBS setup.

This patch fixes IBS setup after waking up from S3 by adding
resume/supend hooks for the boot cpu which does the offset
reinitialization.

Marking it as stable to let distros pick up this fix.

Signed-off-by: Robert Richter <rric@kernel.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1389797849-5565-1-git-send-email-rric.net@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully

commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8 upstream.

After a successful hugetlb page migration by soft offline, the source
page will either be freed into hugepage_freelists or buddy(over-commit
page).  If page is in buddy, page_hstate(page) will be NULL.  It will
hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page().

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
  IP: [<ffffffff81163761>] dequeue_hwpoisoned_huge_page+0x131/0x1d0
  PGD c23762067 PUD c24be2067 PMD 0
  Oops: 0000 [#1] SMP

So check PageHuge(page) after call migrate_pages() successfully.

[wujg: backport to 3.4:
 - adjust context
 - s/num_poisoned_pages/mce_bad_pages/]

Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hwmon: (coretemp) Fix truncated name of alarm attributes

commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream.

When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.

Reported-by: Andreas Hollmann <hollmann@in.tum.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()

commit 3dc91d4338d698ce77832985f9cb183d8eeaf6be upstream.

While running stress tests on adding and deleting ftrace instances I hit
this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  IP: selinux_inode_permission+0x85/0x160
  PGD 63681067 PUD 7ddbe067 PMD 0
  Oops: 0000 [#1] PREEMPT
  CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
  Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
  task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
  RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
  RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
  RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
  RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
  R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
  R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
  FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
  CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
  Call Trace:
    security_inode_permission+0x1c/0x30
    __inode_permission+0x41/0xa0
    inode_permission+0x18/0x50
    link_path_walk+0x66/0x920
    path_openat+0xa6/0x6c0
    do_filp_open+0x43/0xa0
    do_sys_open+0x146/0x240
    SyS_open+0x1e/0x20
    system_call_fastpath+0x16/0x1b
  Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
  RIP  selinux_inode_permission+0x85/0x160
  CR2: 0000000000000020

Investigating, I found that the inode->i_security was NULL, and the
dereference of it caused the oops.

in selinux_inode_permission():

	isec = inode->i_security;

	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);

Note, the crash came from stressing the deletion and reading of debugfs
files.  I was not able to recreate this via normal files.  But I'm not
sure they are safe.  It may just be that the race window is much harder
to hit.

What seems to have happened (and what I have traced), is the file is
being opened at the same time the file or directory is being deleted.
As the dentry and inode locks are not held during the path walk, nor is
the inodes ref counts being incremented, there is nothing saving these
structures from being discarded except for an rcu_read_lock().

The rcu_read_lock() protects against freeing of the inode, but it does
not protect freeing of the inode_security_struct.  Now if the freeing of
the i_security happens with a call_rcu(), and the i_security field of
the inode is not changed (it gets freed as the inode gets freed) then
there will be no issue here.  (Linus Torvalds suggested not setting the
field to NULL such that we do not need to check if it is NULL in the
permission check).

Note, this is a hack, but it fixes the problem at hand.  A real fix is
to restructure the destroy_inode() to call all the destructor handlers
from the RCU callback.  But that is a major job to do, and requires a
lot of work.  For now, we just band-aid this bug with this fix (it
works), and work on a more maintainable solution in the future.

Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nilfs2: fix segctor bug that causes file system corruption

commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream.

There is a bug in the function nilfs_segctor_collect, which results in
active data being written to a segment, that is marked as clean.  It is
possible, that this segment is selected for a later segment
construction, whereby the old data is overwritten.

The problem shows itself with the following kernel log message:

  nilfs_sufile_do_cancel_free: segment 6533 must be clean

Usually a few hours later the file system gets corrupted:

  NILFS: bad btree node (blocknr=8748107): level = 0, flags = 0x0, nchildren = 0
  NILFS error (device sdc1): nilfs_bmap_last_key: broken bmap (inode number=114660)

The issue can be reproduced with a file system that is nearly full and
with the cleaner running, while some IO intensive task is running.
Although it is quite hard to reproduce.

This is what happens:

 1. The cleaner starts the segment construction
 2. nilfs_segctor_collect is called
 3. sc_stage is on NILFS_ST_SUFILE and segments are freed
 4. sc_stage is on NILFS_ST_DAT current segment is full
 5. nilfs_segctor_extend_segments is called, which
    allocates a new segment
 6. The new segment is one of the segments freed in step 3
 7. nilfs_sufile_cancel_freev is called and produces an error message
 8. Loop around and the collection starts again
 9. sc_stage is on NILFS_ST_SUFILE and segments are freed
    including the newly allocated segment, which will contain active
    data and can be allocated at a later time
10. A few hours later another segment construction allocates the
    segment and causes file system corruption

This can be prevented by simply reordering the statements.  If
nilfs_sufile_cancel_freev is called before nilfs_segctor_extend_segments
the freed segments are marked as dirty and cannot be allocated any more.

Signed-off-by: Andreas Rohner <andreas.rohner@gmx.net>
Reviewed-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Andreas Rohner <andreas.rohner@gmx.net>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
md/raid10: fix bug when raid10 recovery fails to recover a block.

commit e8b849158508565e0cd6bc80061124afc5879160 upstream.

commit e875ecea266a543e643b19e44cf472f1412708f9
    md/raid10 record bad blocks as needed during recovery.

added code to the "cannot recover this block" path to record a bad
block rather than fail the whole recovery.
Unfortunately this new case was placed *after* r10bio was freed rather
than *before*, yet it still uses r10bio.
This is will crash with a null dereference.

So move the freeing of r10bio down where it is safe.

Fixes: e875ecea266a543e643b19e44cf472f1412708f9
Reported-by: Damian Nowak <spam@nowaker.net>
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
md/raid10: fix two bugs in handling of known-bad-blocks.

commit b50c259e25d9260b9108dc0c2964c26e5ecbe1c1 upstream.

If we discover a bad block when reading we split the request and
potentially read some of it from a different device.

The code path of this has two bugs in RAID10.
1/ we get a spin_lock with _irq, but unlock without _irq!!
2/ The calculation of 'sectors_handled' is wrong, as can be clearly
   seen by comparison with raid1.c

This leads to at least 2 warnings and a probable crash is a RAID10
ever had known bad blocks.

Fixes: 856e08e23762dfb92ffc68fd0a8d228f9e152160
Reported-by: Damian Nowak <spam@nowaker.net>
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.4.78
ipv4: Change ICP Defaults

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
Defconfig: Add More TCP Options

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
Merge tag 'v3.4.78' into cm-11-old

This is the 3.4.78 stable release

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>

Conflicts:
	arch/x86/kernel/cpu/perf_event_amd_ibs.c
Revert "BFQ V6r2"

This reverts commit 39193cbb3fefb39c5575f51235b9e4a15031d036.
BFQ-V7

CHANGELOG

v7:
- IMPROVEMENT: In the presence of weight-raised queues and if the
  device is NCQ-enabled, device idling is now disabled for non-raised
  readers, i.e., for their associated sync queues. Hence a sync queue
  is expired immediately if it becomes empty, and a new queue is
  served.  As explained in detail in the papers about BFQ, not idling
  the device for sync queues when the latter become empty causes BFQ to
  assign higher timestamps to these queues when they get backlogged
  again, and hence to serve these queues less frequently. This fact,
  plus to the fact that, because of the immediate expiration itself,
  these queues get less service while they are granted access to the
  disk, reduces the relative rate at which the processes associated to
  these queues ask for requests from the I/O request pool. If the pool
  is saturated, as it happens, in the presence of write hogs, reducing
  the above relative rate increases the probability that a request is
  available (soon) in the pool when a weight-raised process needs it.
  This change does seem to mitigate the typical starvation problems
  that occur in the presence of write hogs and NCQ, and hence to
  guarantee a higher application and system responsiveness in these
  hostile scenarios.
- IMPROVEMENT/BUGFIX: Introduced a new classification rule to the soft
  real-time heuristic, which takes into account also the isochronous
  nature of such applications. The computation of next_start has been
  fixed as well. Now it is correctly done from the time of the last
  transition from idle to backlogged; the next_start is therefore
  computed from the service received by the queue from its last
  transition from idle to backlogged. Finally, the code which
  preserved weight-raising for a soft real-time queue even with no
  idle->backlogged transition has been removed.
- IMPROVEMENT: Add a few jiffies to the reference time interval used to
  establish whether an application is greedy or not. This reference
  interval was, by default, HZ/125 seconds, which could generate false
  positives in the following two cases (especially if both cases occur):
  1) If HZ is so low that the duration of a jiffie is comparable to or
     higher than the above reference time interval. This happens, e.g.,
     on slow devices with HZ=100.
  2) If jiffies, instead of increasing at a constant rate, may stop
     increasing for some time, then suddenly 'jump' by several units to
     recover the lost increments. This seems to happen, e.g., in virtual
     machines.
  The added number of jiffies has been found experimentally. In particular,
  according to our experiments, adding this number of jiffies seems to make
  the filter quite precise also in embedded systems and KVM/QEMU virtual
  machines. Also contributed by
  Alexander Spyridakis <a.spyridakis@virtualopensystems.com>.
- IMPROVEMENT/BUGFIX: Keep disk idling also for NCQ-provided
  rotational devices, which boosts the throughput on NCQ-enabled
  rotational devices.
- BUGFIX: The budget-timeout condition in the bfq_rq_enqueued() function
  was checked only if the request is large enough to provoke an unplug. As
  a consequence, for a process always issuing small I/O requests the
  budget timeout was never checked. The queue associated to the process
  therefore expired only when its budget was exhausted, even if the
  queue had already incurred a budget timeout from a while.
  This fix lets a queue be checked for budget timeout at each request
  enqueue, and, if needed, expires the queue accordingly even if the
  request is small.
- BUGFIX: Make sure that weight-raising is resumed for a split queue,
  if it was merged when already weight-raised.
- MINOR BUGFIX: Let bfq_end_raising_async() correctly end weight-raising
  also for the queues belonging to the root group.
- IMPROVEMENT: Get rid of the some_coop_idle flag, which in its turn
  was used to decide whether to disable idling for an in-service
  shared queue whose seek mean decreased. In fact, disabling idling
  for such a queue turned out to be useless.
- CODE IMPROVEMENT: The bfq_bfqq_must_idle() function and the
  bfq_select_queue() function may not change the current in-service
  queue in various cases. We have cleaned up the involved conditions,
  by factoring out the common parts and getting rid of the useless
  ones.
- MINOR CODE IMPROVEMENT: The idle_for_long_time condition in the
  bfq_add_rq_rb() function should be evaluated only on an
  idle->backlogged transition. Now the condition is set to false
  by default, evaluating it only if the queue was not busy on a
  request insertion.
- MINOR CODE IMPROVEMENT: Added a comment describing the rationale
  behind the condition evalutated in the function
  bfq_bfqq_must_not_expire().

v6r2:
- Fairness fix: the case of queue expiration for budget timeout is
  now correctly handled also for sync queues, thus allowing also
  the processes corresponding to these queues to be guaranteed their
  reserved share of the disk throughput.
- Fixed a bug that prevented group weights from being correctly
  set via the sysfs interface.
- Fixed a bug that cleared a previously-set group weight if the
  same value was re-inserted via the sysfs interface.
- Fixed an EQM bug that allowed a newly-started process to skip
  its initial weight-raising period if its queue was merged before
  its first request was inserted.
- Fixed a bug that preserved already-started weight-raising periods
  even if the low_latency tunable was disabled.
- The raising_max_time tunable now shows, more user-friendly, the
  maximum raising time in milliseconds.

v6r1:
- Fix use-after-free of queues in __bfq_bfqq_expire(). It may happen that
  a call to bfq_del_bfqq_busy() puts the last reference taken on a queue
  and frees it. Subsequent accesses to that same queue would result in a
  use-after-free. Make sure that a queue that has just been deleted from
  busy is no more touched.
- Use the uninitialized_var() macro when needed. It may happen that a
  variable is initialized in a function that is called by the function
  that defined it. Use the uninitialized_var() macro in these cases.

v6:
- Replacement of the cooperating-queue merging mechanism borrowed from
  CFQ with Early Queue Merge (EQM), a unified mechanism to get a
  sequential read pattern, and hence a high throughput, with any set of
  processes performing interleaved I/O. EQM also preserves low latency.
  (see http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
  for more details). Contributed by Mauro Andreolini and Arianna Avanzini.
  The code for detecting whether two queues have to be merged is a
  slightly modified version of the CFQ code for detecting whether two
  queues belong to cooperating processes and whether the service of a
  queue should be preempted to boost the throughput.
- Fix a bug that caused the peak rate of a disk to be computed as zero
  in case of multiple I/O errors. Subsequent estimations of the weight
  raising duration caused a division-by-zero error.

v5r1:
- BUG FIX: Fixed stall occurring when the active queue is moved to
  a different group while idling (this caused the idling timer to be
  cancelled and hence no new queue to be selected, and no new
  request to be dispatched).
- BUG FIX: Fixed wrong assignment of too high budgets to queues during
  the first few seconds after initialization.
- BUG FIX: Added proper locking to the function handling the "weights"
  tunable.

v5:
- Added an heuristic that, if the tunable raising_max_time is set to
  0, automatically computes the duration of the weight raising
  according to the estimated peak rate of the device. This enables
  flash-based devices to reach maximum throughput as soon as possible,
  without sacrificing latency.

v4:
- Throughput-boosting for flash-based devices: improved version of commits
  a68bbdd and f7d7b7a, which boosts the throughput while still preserving
  latency guarantees for interactive and soft real-time applications.
- Better identification of NCQ-capable disks: port of commit e459dd0.

v3-r4:
- Bugfixes
  * Removed an important memory leak: under some circumstances the process references
    to a queue were not decremented correctly, which prevented unused shared bfq_queue
    to be correctly deallocated.
  * Fixed various errors related to hierarchical scheduling:
	* Removed an error causing tasks to be attached to the bfqio cgroup
	  controller even when BFQ was not the active scheduler
	* Corrected wrong update of the budgets from the leaf to the root upon
	  forced selection of a service tree or a bfq_queue
	* Fixed the way how active leaf entities are moved to the root group before
	  the group entity is deactivated when a cgroup is destroyed
- Throughput-boosting improvement for cooperating queues: close detection is now based
  on a fixed threshold instead of the queue's average seek. This is a port of one of
  the changes in the CFQ commit 3dde36d by Corrado Zoccolo.

v3-r3:
- Bugfix: removed an important error causing occasional kernel panics when
  moving a process to a new cgroup. The panic occurred if:
  1) the queue associated to the process was idle when the process was moved
     and
  2) a new disk request was inserted into the queue just after the move.
- Further latency improvement through a better treatment of low-bandwidth
  async queues.

v3-r2:
- Bugfix: added a forgotten condition that prevents weights of low-bw async
  queues from being raised when low_latency is off.
- Latency improvement: low-bw async queues are now better identified.

v3-r1:
- Fixed an important request-dispatch bug causing occasional IO hangs.
- Added a new mechanism to reduce the latency of low-bw async queues.
  This reduces the latency of also the sync queues synchronized with
  the above async queues.
- Fixed a minor bug in iocontext locking (port of commits 9b50902 and 3181faa
  from CFQ).

v3:

- Improved low-latency mechanisms, including a more accurate criterion to
  distinguish between greedy-but-seeky and soft real-time applications.
  Interactive applications now enjoy noticeably lower latencies.

- Switch to the simpler one-request-dispatch-at-a-time scheme as in CFQ.

- Ported cooperating-queues merging from CFQ (6d048f5, 1afba04,
  d9e7620, a36e71f, 04dc6e7, 26a2ac0, 3ac6c9f, f2d1f0a, 83096eb,
  2e46e8b, df5fe3e, b3b6d04, e6c5bc7, c0324a0, f04a642, 8682e1f,
  b9d8f4c, 2f7a2d8, ae54abe, e9ce335, 39c01b2, d02a2c0, c10b61f).
  Contributed by Arianna Avanzini. Queues of processes performing IO
  on interleaved, yet contiguous disk zones are merged to boost the
  throughput. Some little optimizations to get a more stable throughput
  have been added to the original CFQ version.

- Added static fallback queue for extreme OOM conditions (porting of
  CFQ commits d5036d7, 6118b70, b706f64, 32f2e80). Port contributed by
  Francesco Allertsen.

- Ported CFQ commits b0b78f8, 40bb54d, 30996f4, dddb745, ad5ebd2, cf7c25c;
  mainly code cleanup and fix of minor bugs. Port contributed by
  Francesco Allertsen.

v2:

- An issue that may cause little throughput loss on fast disks has been solved.
  BFQ-v1 and CFQ may suffer from this problem.
- The disk-idling timeout has been better tuned to further file latency
  (especially for the idle- or light-loaded-disk scenarios).
- One of the parameters of the low-latency heuristics has been tuned a little
  bit more, so as to reduce the probability that a disk-bound process may
  hamper the reduction of the latency of interactive and soft real-time
  applications.

  - Same low-latency guarantees with and without NCQ.

  - Latency for interactive applications about halved with respect to BFQ-v1.

  - When the low_latency tunable is set, also soft real-time applications
    now enjoy reduced latency.

  - A very little minimum bandwidth is now guaranteed to the
    Idle IO-scheduling class also when the other classes are
    backlogged, just to prevent them from starving.

v1:

This is a new version of BFQ with respect to the versions you can
find on Fabio's site: http://feanor.sssup.it/~fabio/linux/bfq.
Here is what we changed with respect to the previous versions:

1) re-tuned the budget feedback mechanism: it is now slighlty more
biased toward assigning high budgets, to boost the aggregated
throughput more, and more quickly as new processes are started

2) introduced more tolerance toward seeky queues (I verified that the
phenomenona described below used to occurr systematically):

   2a: if a queue is expired after having received very little
       service, then it is not punished as a seeky queue, even if it
       occurred to consume that little service too slowly; the
       rationale is that, if the new active queue has been served for
       a too short time interval, then its possible sequential
       accesses may not yet prevail on the initial latencies for
       moving the disk head on the first sector requested

   2b: the waiting time (disk idling) of a queue detected as seeky as
       a function of the position of the requests it issued is reduced
       to a very low value only after the queue has consumed a minimum
       fraction of the assigned budget; this prevents processes
       generating (partly) seeky workloads from being too ill-treated

   2c: if a queue has consumed 'enough' budget upon a budget timeout, then,
       even if it did not consume all of its budget, that queue is not punished
       as any seeky queue; the rationale is that, depending on the disk zones,
       a queue may be served at a lower rate than the estimated peak rate.

   Changes 2a and 2b have been critical in lowering latencies, whereas
   change 2c, in addition to change 1, helped a lot increase the disk
   throughput.

3) slightly changed the peak rate estimator: a low-pass filter is now
used instead of just keeping the highest rate sampled; the rationale
is that the peak rate of a disk should be quite stable, so the filter
should converge more or less smoothly to the right value; it seemed to
correctly catch the peak rate with all disks we used

4) added the low latency mechanism described in detail in
http://algo.ing.unimo.it/people/paolo/disk_sched/description.php.

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
DIABLO 1.4

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>