01 Jun, 2012
1 commit
-
commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 upstream.
6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
added part_unpack_uuid() which assumes that the passed in buffer has
enough space for sprintfing "%pU" - 37 characters including '\0'.Unfortunately, b5af921ec0233 "init: add support for root devices
specified by partition UUID" supplied 33 bytes buffer to the function
leading to the following panic with stackprotector enabled.Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e
[] panic+0xba/0x1c6
[] ? printk_all_partitions+0x259/0x26xb
[] __stack_chk_fail+0x1b/0x20
[] printk_all_paritions+0x259/0x26xb
[] mount_block_root+0x1bc/0x27f
[] mount_root+0x57/0x5b
[] prepare_namespace+0x13d/0x176
[] ? release_tgcred.isra.4+0x330/0x30
[] kernel_init+0x155/0x15a
[] ? schedule_tail+0x27/0xb0
[] kernel_thread_helper+0x5/0x10
[] ? start_kernel+0x3c5/0x3c5
[] ? gs_change+0x13/0x13Increase the buffer size, remove the dangerous part_unpack_uuid() and
use snprintf() directly from printk_all_partitions().Signed-off-by: Tejun Heo
Reported-by: Szymon Gruszczynski
Cc: Will Drewry
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
19 Mar, 2012
2 commits
-
commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.
This patch (as1519) fixes a bug in the block layer's disk-events
polling. The polling is done by a work routine queued on the
system_nrt_wq workqueue. Since that workqueue isn't freezable, the
polling continues even in the middle of a system sleep transition.Obviously, polling a suspended drive for media changes and such isn't
a good thing to do; in the case of USB mass-storage devices it can
lead to real problems requiring device resets and even re-enumeration.The patch fixes things by creating a new system-wide, non-reentrant,
freezable workqueue and using it for disk-events polling.Signed-off-by: Alan Stern
Acked-by: Tejun Heo
Acked-by: Rafael J. Wysocki
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream.
The following situation might occur:
__blkdev_get: add_disk:
register_disk()
get_gendisk()disk_block_events()
disk->ev == NULLdisk_add_events()
__disk_unblock_events()
disk->ev != NULL
--ev->blockThen we unblock events, when they are suppose to be blocked. This can
trigger events related block/genhd.c warnings, but also can crash in
sd_check_events() or other places.I'm able to reproduce crashes with the following scripts (with
connected usb dongle as sdb disk).DEV=/dev/sdb
ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValuefunction stop_me()
{
for i in `jobs -p` ; do kill $i 2> /dev/null ; done
exit
}trap stop_me SIGHUP SIGINT SIGTERM
for ((i = 0; i < 10; i++)) ; do
while true; do fdisk -l $DEV 2>&1 > /dev/null ; done &
donewhile true ; do
echo 1 > $ENABLE
sleep 1
echo 0 > $ENABLE
doneI use the script to verify patch fixing oops in sd_revalidate_disk
http://marc.info/?l=linux-scsi&m=132935572512352&w=2
Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in
sd_revalidate_disk" or this one, script easily crash kernel within
a few seconds. With both patches applied I do not observe crash.
Unfortunately after some time (dozen of minutes), script will hung in:[ 1563.906432] [] schedule_timeout_uninterruptible+0x15/0x20
[ 1563.906437] [] msleep+0x15/0x20
[ 1563.906443] [] blk_drain_queue+0x32/0xd0
[ 1563.906447] [] blk_cleanup_queue+0xd0/0x170
[ 1563.906454] [] scsi_free_queue+0x3f/0x60
[ 1563.906459] [] __scsi_remove_device+0x6e/0xb0
[ 1563.906463] [] scsi_forget_host+0x4f/0x60
[ 1563.906468] [] scsi_remove_host+0x5a/0xf0
[ 1563.906482] [] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
[ 1563.906490] [] usb_stor_disconnect+0x13/0x20 [usb_storage]Anyway I think this patch is some step forward.
As drawback, I do not teardown on sysfs file create error, because I do
not know how to nullify disk->ev (since it can be used). However add_disk
error handling practically does not exist too, and things will work
without this sysfs file, except events will not be exported to user
space.Signed-off-by: Stanislaw Gruszka
Acked-by: Tejun Heo
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2012
1 commit
-
commit 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3 upstream.
We create "bsg" link if q->kobj.sd is not NULL, so remove it only
when the same condition is true.Fixes:
WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77()
sysfs: can not remove 'bsg', no directory
Call Trace:
[] warn_slowpath_common+0x6a/0x7f
[] ? sysfs_hash_and_remove+0x2b/0x77
[] warn_slowpath_fmt+0x2b/0x2f
[] sysfs_hash_and_remove+0x2b/0x77
[] sysfs_remove_link+0x20/0x23
[] bsg_unregister_queue+0x40/0x6d
[] __scsi_remove_device+0x31/0x9d
[] scsi_forget_host+0x41/0x52
[] scsi_remove_host+0x71/0xe0
[] quiesce_and_remove_host+0x51/0x83 [usb_storage]
[] usb_stor_disconnect+0x18/0x22 [usb_storage]
[] usb_unbind_interface+0x4e/0x109
[] __device_release_driver+0x6b/0xa6
[] device_release_driver+0x17/0x22
[] bus_remove_device+0xd6/0xe6
[] device_del+0xf2/0x137
[] usb_disable_device+0x94/0x1a0Signed-off-by: Stanislaw Gruszka
Signed-off-by: Jens Axboe
Signed-off-by: Tim Gardner
Signed-off-by: Greg Kroah-Hartman
26 Jan, 2012
2 commits
-
commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.
[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
and -ENOIOCTLCMD from sd_compat_ioctl. ]Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device. This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice. Still, I'm treating it specially to avoid spamming the logs.In principle, this restriction should include programs running with
CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities. However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls. Their actions will still be logged.This patch does not affect the non-libata IDE driver. That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Cc: James Bottomley
Signed-off-by: Paolo Bonzini
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.
Introduce a wrapper around scsi_cmd_ioctl that takes a block device.
The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Cc: James Bottomley
Signed-off-by: Paolo Bonzini
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
07 Jan, 2012
3 commits
-
commit 5151412dd4338b273afdb107c3772528e9e67d92 upstream.
struct request_queue is allocated with __GFP_ZERO so its "node" field is
zero before initialization. This causes an oops if node 0 is offline in
the page allocator because its zonelists are not initialized. From Dave
Young's dmesg:SRAT: Node 1 PXM 2 0-d0000000
SRAT: Node 1 PXM 2 100000000-330000000
SRAT: Node 0 PXM 1 330000000-630000000
Initmem setup node 1 0000000000000000-000000000affb000
...
Built 1 zonelists in Node order, mobility grouping on.
...
BUG: unable to handle kernel paging request at 0000000000001c08
IP: [] __alloc_pages_nodemask+0xb5/0x870and __alloc_pages_nodemask+0xb5 translates to a NULL pointer on
zonelist->_zonerefs.The fix is to initialize q->node at the time of allocation so the correct
node is passed to the slab allocator later.Since blk_init_allocated_queue_node() is no longer needed, merge it with
blk_init_allocated_queue().[rientjes@google.com: changelog, initializing q->node]
Reported-by: Dave Young
Signed-off-by: Mike Snitzer
Signed-off-by: David Rientjes
Tested-by: Dave Young
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 5eb46851de3904cd1be9192fdacb8d34deadc1fc upstream.
cfq_cic_link() has race condition. When some processes which shared ioc
issue I/O to same block device simultaneously, cfq_cic_link() returns -EEXIST
sometimes. The race condition might stop I/O by following steps:step 1: Process A: Issue an I/O to /dev/sda
step 2: Process A: Get an ioc (iocA here) in get_io_context() which does not
linked with a cic for the device
step 3: Process A: Get a new cic for the device (cicA here) in
cfq_alloc_io_context()step 4: Process B: Issue an I/O to /dev/sda
step 5: Process B: Get iocA in get_io_context() since process A and B share the
same ioc
step 6: Process B: Get a new cic for the device (cicB here) in
cfq_alloc_io_context() since iocA has not been linked with a
cic for the device yetstep 7: Process A: Link cicA to iocA in cfq_cic_link()
step 8: Process A: Dispatch I/O to driver and finish itstep 9: Process B: Try to link cicB to iocA in cfq_cic_link()
But it fails with showing "cfq: cic link failed!" kernel
message, since iocA has already linked with cicA at step 7.
step 10: Process B: Wait for finishig I/O in get_request_wait()
The function does not wake up, when there is no I/O to the
device.When cfq_cic_link() returns -EEXIST, it means ioc has already linked with cic.
So when cfq_cic_link() return -EEXIST, retry cfq_cic_lookup().Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 2984ff38ccf6cbc02a7a996a36c7d6f69f3c6146 upstream.
If we fail allocating the blkpg stats, we free cfqd and cfgq.
But we need to free the IDA cfqd->cic_index as well.Signed-off-by: majianpeng
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
22 Nov, 2011
1 commit
-
commit 6b76106d8ef31111d6fc469564b83b5f5542794f upstream.
Even after commit 5478755616ae2ef1ce144dded589b62b2a50d575
("block: check for proper length of iov entries earlier ...")
we still won't check for zero-length entries after an unaligned
entry. Remove the break-statement, so all entries are checked.Signed-off-by: Ben Hutchings
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
12 Nov, 2011
1 commit
-
commit f992ae801a7dec34a4ed99a6598bbbbfb82af4fb upstream.
The following command sequence triggers an oops.
# mount /dev/sdb1 /mnt
# echo 1 > /sys/class/scsi_device/0\:0\:1\:0/device/delete
# umount /mntgeneral protection fault: 0000 [#1] PREEMPT SMP
CPU 2
Modules linked in:Pid: 791, comm: umount Not tainted 3.1.0-rc3-work+ #8 Bochs Bochs
RIP: 0010:[] [] __lock_acquire+0x389/0x1d60
...
Call Trace:
[] lock_acquire+0x95/0x140
[] _raw_spin_lock+0x3b/0x50
[] bdi_lock_two+0x5c/0x70
[] bdev_inode_switch_bdi+0x4c/0xf0
[] __blkdev_put+0x11b/0x1d0
[] __blkdev_put+0x160/0x1d0
[] blkdev_put+0x5f/0x190
[] kill_block_super+0x4d/0x80
[] deactivate_locked_super+0x45/0x70
[] deactivate_super+0x4a/0x70
[] mntput_no_expire+0xed/0x130
[] sys_umount+0x7e/0x3a0
[] system_call_fastpath+0x16/0x1bThis is because bdev holds on to disk but disk doesn't pin the
associated queue. If a SCSI device is removed while the device is
still open, the sdev puts the base reference to the queue on release.
When the bdev is finally released, the associated queue is already
gone along with the bdi and bdev_inode_switch_bdi() ends up
dereferencing already freed bdi.Even if it were not for this bug, disk not holding onto the associated
queue is very unusual and error-prone.Fix it by making add_disk() take an extra reference to its queue and
put it on disk_release() and ensuring that disk and its fops owner are
put in that order after all accesses to the disk and queue are
complete.Signed-off-by: Tejun Heo
Cc: Jens Axboe
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
04 Oct, 2011
2 commits
-
commit 777eb1bf15b8532c396821774bf6451e563438f5 upstream.
A kernel crash is observed when a mounted ext3/ext4 filesystem is
physically removed. The problem is that blk_cleanup_queue() frees up
some resources eg by calling elevator_exit(), which are not checked for
in normal operation. So we should rather move these calls to the
destructor function blk_release_queue() as at that point all remaining
references are gone. However, in doing so we have to ensure that any
externally supplied queue_lock is disconnected as the driver might free
up the lock after the call of blk_cleanup_queue(),Signed-off-by: Hannes Reinecke
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit d11bb4462c4cc6ddd45c6927c617ad79fa6fb8fc upstream.
The bug is we're not able to remove the device from blkio cgroup's
per-device control files if it gets unplugged.To reproduce the bug:
# mount -t cgroup -o blkio xxx /cgroup
# cd /cgroup
# echo "8:0 1000" > blkio.throttle.read_bps_device
# unplug the device
# cat blkio.throttle.read_bps_device
8:0 1000
# echo "8:0 0" > blkio.throttle.read_bps_device
-bash: echo: write error: No such deviceAfter patching, the device removal will succeed.
Thanks for the comments of Paul, Zefan, and Vivek.
Signed-off-by: Wanlong Gao
Cc: Li Zefan
Cc: Paul Menage
Acked-by: Vivek Goyal
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
05 Aug, 2011
1 commit
-
commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 upstream.
USB surprise removal of sr is triggering an oops in
scsi_dispatch_command(). What seems to be happening is that USB is
hanging on to a queue reference until the last close of the upper
device, so the crash is caused by surprise remove of a mounted CD
followed by attempted unmount.The problem is that USB doesn't issue its final commands as part of
the SCSI teardown path, but on last close when the block queue is long
gone. The long term fix is probably to make sr do the teardown in the
same way as sd (so remove all the lower bits on ejection, but keep the
upper disk alive until last close of user space). However, the
current oops can be simply fixed by not allowing any commands to be
sent to a dead queue.Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
27 Jun, 2011
2 commits
-
ioc->ioc_data is rcu protectd, so uses correct API to access it.
This doesn't change any behavior, but just make code consistent.Signed-off-by: Shaohua Li
Cc: stable@kernel.org # after ab4bd22d
Signed-off-by: Jens Axboe -
I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but
doesn't hold rcu_read_lock.Signed-off-by: Shaohua Li
Cc: stable@kernel.org # after ab4bd22d
Signed-off-by: Jens Axboe
13 Jun, 2011
1 commit
-
Use the compiler to verify format strings and arguments.
Fix fallout.
Signed-off-by: Joe Perches
Signed-off-by: Jens Axboe
10 Jun, 2011
3 commits
-
disk_block_events() should guarantee that the event work is not in
flight on return and once blocked it shouldn't issue further
cancellations.Because there was no synchronization between the first blocker doing
cancel_delayed_work_sync() and the following blockers, the following
blockers could finish before cancellation was complete, which broke
both guarantees - event work could be in flight and cancellation could
happen after return.This bug triggered WARN_ON_ONCE() in disk_clear_events() reported in
bug#34662.https://bugzilla.kernel.org/show_bug.cgi?id=34662
Fix it by adding an outer mutex which protects both block count
manipulation and work cancellation.-v2: Use outer mutex instead of bit waitqueue per Linus.
Signed-off-by: Tejun Heo
Tested-by: Sitsofe Wheeler
Reported-by: Sitsofe Wheeler
Reported-by: Borislav Petkov
Reported-by: Meelis Roos
Reported-by: Linus Torvalds
Cc: Andrew Morton
Cc: Jens Axboe
Cc: Kay Sievers
Signed-off-by: Jens Axboe -
After the previous update to disk_check_events(), nobody is using
non-syncing __disk_block_events(). Remove @sync and, as this makes
__disk_block_events() virtually identical to disk_block_events(),
remove the underscore prefixed version.Signed-off-by: Tejun Heo
Cc: Jens Axboe
Signed-off-by: Jens Axboe -
This patch is part of fix for triggering of WARN_ON_ONCE() in
disk_clear_events() reported in bug#34662.https://bugzilla.kernel.org/show_bug.cgi?id=34662
disk_clear_events() blocks events, schedules and flushes the event
work. It expects the work to have started execution on schedule and
finished on return from flush. WARN_ON_ONCE() triggers if the event
work hasn't executed as expected. This problem happens because
__disk_block_events() fails to guarantee that the event work item is
not in flight on return from the function in race-free manner. The
problem is two-fold and this patch addresses one of them.When __disk_block_events() is called with @sync == %false, it bumps
event block count, calls cancel_delayed_work() and return. This makes
it impossible to guarantee that event polling is not in flight on
return from syncing __disk_block_events() - if the first blocker was
non-syncing, polling could still be in progress and later syncing ones
would assume that the first blocker already canceled it.Making __disk_block_events() cancel_sync regardless of block count
isn't feasible either as it may race with forced event checking in
disk_clear_events().As disk_check_events() is the only user of non-syncing
__disk_block_events(), updating it to directly cancel and schedule
event work is the easiest way to solve the issue.Note that there's another bug in __disk_block_events() and this patch
doesn't fix the issue completely. Later patch will fix the other bug.Signed-off-by: Tejun Heo
Tested-by: Sitsofe Wheeler
Reported-by: Sitsofe Wheeler
Reported-by: Borislav Petkov
Reported-by: Meelis Roos
Reported-by: Linus Torvalds
Cc: Andrew Morton
Cc: Jens Axboe
Cc: Kay Sievers
Signed-off-by: Jens Axboe
06 Jun, 2011
1 commit
-
Since we are modifying this RCU pointer, we need to hold
the lock protecting it around it.This fixes a potential reuse and double free of a cfq
io_context structure. The bug has been in CFQ for a long
time, it hit very few people but those it did hit seemed
to see it a lot.Tracked in RH bugzilla here:
https://bugzilla.redhat.com/show_bug.cgi?id=577968
Credit goes to Paul Bolle for figuring out that the issue
was around the one-hit ioc->ioc_data cache. Thanks to his
hard work the issue is now fixed.Cc: stable@kernel.org
Signed-off-by: Jens Axboe
02 Jun, 2011
2 commits
-
list_entry() and hlist_entry() are both simply aliases for
container_of(), but since io_context.cic_list.first is an hlist_node one
should at least use the correct alias.Signed-off-by: Paul Bolle
Signed-off-by: Jens Axboe -
queue_fail can only be reached if cic is NULL, so its check for cic must
be bogus.Signed-off-by: Paul Bolle
Signed-off-by: Jens Axboe
01 Jun, 2011
1 commit
-
Fix comment typo and remove unnecessary semicolon at macro
Signed-off-by: Kyungmin Park
Signed-off-by: Jens Axboe
28 May, 2011
1 commit
-
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
loop: export module parameters
block: export blk_{get,put}_queue()
block: remove unused variable in bio_attempt_front_merge()
block: always allocate genhd->ev if check_events is implemented
brd: export module parameters
brd: fix comment on initial device creation
brd: handle on-demand devices correctly
brd: limit 'max_part' module param to DISK_MAX_PARTS
brd: get rid of unused members from struct brd_device
block: fix oops on !disk->queue and sysfs discard alignment display
27 May, 2011
4 commits
-
We need them in SCSI to fix a bug, but currently they are not
exported to modules. Export them.Signed-off-by: Jens Axboe
-
Add cgroup subsystem callbacks for per-thread attachment in atomic contexts
Add can_attach_task(), pre_attach(), and attach_task() as new callbacks
for cgroups's subsystem interface. Unlike can_attach and attach, these
are for per-thread operations, to be called potentially many times when
attaching an entire threadgroup.Also, the old "bool threadgroup" interface is removed, as replaced by
this. All subsystems are modified for the new interface - of note is
cpuset, which requires from/to nodemasks for attach to be globally scoped
(though per-cpuset would work too) to persist from its pre_attach to
attach_task and attach.This is a pre-patch for cgroup-procs-writable.patch.
Signed-off-by: Ben Blum
Cc: "Eric W. Biederman"
Cc: Li Zefan
Cc: Matt Helsley
Reviewed-by: Paul Menage
Cc: Oleg Nesterov
Cc: David Rientjes
Cc: Miao Xie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sector is never read inside the function.
Signed-off-by: Luca Tettamanti
Signed-off-by: Jens Axboe -
9fd097b149 (block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe
drivers) removed DISK_EVENT_MEDIA_CHANGE from legacy/fringe block
drivers which have inadequate ->check_events(). Combined with earlier
change 7c88a168da (block: don't propagate unlisted DISK_EVENTs to
userland), this enables using ->check_events() for internal processing
while avoiding enabling in-kernel block event polling which can lead
to infinite event loop.Unfortunately, this made many drivers including floppy without any bit
set in disk->events and ->async_events in which case disk_add_events()
simply skipped allocation of disk->ev, which disables whole event
handling. As ->check_events() is still used during open processing
for revalidation, this can lead to open failure.This patch always allocates disk->ev if ->check_events is implemented.
In the long term, it would make sense to simply include the event
structure inline into genhd as it's now used by virtually all block
devices.Signed-off-by: Tejun Heo
Reported-by: Ondrej Zary
Reported-by: Alex Villacis Lasso
Cc: stable@kernel.org
Signed-off-by: Jens Axboe
24 May, 2011
5 commits
-
When struct cfq_data allocation fails, cic_index need to be freed.
Signed-off-by: Namhyung Kim
Signed-off-by: Jens Axboe -
The 'group_changed' variable is initialized to 0 and never changed, so
checking the variable is meaningless.It is a leftover from 0bbfeb832042 ("cfq-iosched: Always provide group
iosolation."). Let's get rid of it.Signed-off-by: Namhyung Kim
Cc: Justin TerAvest
Signed-off-by: Jens Axboe -
Reduce the number of bit operations in cfq_choose_req() on average
(and worst) cases.Signed-off-by: Namhyung Kim
Signed-off-by: Jens Axboe -
Simplify the calculation in cfq_prio_to_maxrq(), plus replace CFQ_PRIO_LISTS to
IOPRIO_BE_NR since they are the same and IOPRIO_BE_NR looks more reasonable in
this context IMHO.Signed-off-by: Namhyung Kim
Signed-off-by: Jens Axboe -
If we don't explicitly initialize it to zero, CFQ might think that
cgroup of ioc has changed and it generates lots of unnecessary calls
to call_for_each_cic(changed_cgroup). Fix it.cfq_get_io_context()
cfq_ioc_set_cgroup()
call_for_each_cic(ioc, changed_cgroup)Signed-off-by: Vivek Goyal
Signed-off-by: Jens Axboe
23 May, 2011
3 commits
-
Commit 73c101011926 ("block: initial patch for on-stack per-task plugging")
removed calls to elv_bio_merged() when @bio merged with @req. Re-add them.This in turn will update merged stats in associated group. That
should be safe as long as request has got reference to the blkio_group.Signed-off-by: Namhyung Kim
Cc: Divyesh Shah
Signed-off-by: Jens Axboe -
Make BLKIO_STAT_MERGED per cpu hence gettring rid of need of taking
blkg->stats_lock.Signed-off-by: Vivek Goyal
Signed-off-by: Jens Axboe -
We allocated per cpu stats struct for root group but did not free it.
Fix it.Signed-off-by: Vivek Goyal
Signed-off-by: Jens Axboe
21 May, 2011
3 commits
-
We don't need them anymore, so kill:
- REQ_ON_PLUG checks in various places
- !rq_mergeable() check in plug mergingSigned-off-by: Jens Axboe
-
This patch merges in a fix that missed 2.6.39 final.
Conflicts:
block/blk.h -
Currently we take a queue lock on each bio to check if there are any
throttling rules associated with the group and also update the stats.
Now access the group under rcu and update the stats without taking
the queue lock. Queue lock is taken only if there are throttling rules
associated with the group.So the common case of root group when there are no rules, save
unnecessary pounding of request queue lock.Signed-off-by: Vivek Goyal
Signed-off-by: Jens Axboe