[PATCH v2] blk: improve order of bio handling in generic_make_request()

2017-03-07 Thread NeilBrown
To avoid recursion on the kernel stack when stacked block devices are in use, generic_make_request() will, when called recursively, queue new requests for later handling. They will be handled when the make_request_fn for the current bio completes. If any bios are submitted by a make_request_fn,

Re: [PATCH] zram: set physical queue limits to avoid array out of bounds accesses

2017-03-07 Thread Johannes Thumshirn
On 03/07/2017 09:55 AM, Minchan Kim wrote: > On Tue, Mar 07, 2017 at 08:48:06AM +0100, Hannes Reinecke wrote: >> On 03/07/2017 08:23 AM, Minchan Kim wrote: >>> Hi Hannes, >>> >>> On Tue, Mar 7, 2017 at 4:00 PM, Hannes Reinecke wrote: On 03/07/2017 06:22 AM, Minchan Kim wrote:

Re: [PATCH 01/11] block: Fix bdi assignment to bdev inode when racing with disk delete

2017-03-07 Thread Hannes Reinecke
On 03/06/2017 05:33 PM, Jan Kara wrote: > When disk->fops->open() in __blkdev_get() returns -ERESTARTSYS, we > restart the process of opening the block device. However we forget to > switch bdev->bd_bdi back to noop_backing_dev_info and as a result bdev > inode will be pointing to a stale bdi. Fix

Re: [PATCH RFC 01/14] block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler

2017-03-07 Thread Jens Axboe
On 03/05/2017 09:02 AM, Paolo Valente wrote: > >> Il giorno 05 mar 2017, alle ore 16:16, Jens Axboe ha >> scritto: >> >> On 03/04/2017 09:01 AM, Paolo Valente wrote: >>> We tag as v0 the version of BFQ containing only BFQ's engine plus >>> hierarchical support. BFQ's engine is

Re: [PATCH] zram: set physical queue limits to avoid array out of bounds accesses

2017-03-07 Thread Hannes Reinecke
On 03/07/2017 08:23 AM, Minchan Kim wrote: > Hi Hannes, > > On Tue, Mar 7, 2017 at 4:00 PM, Hannes Reinecke wrote: >> On 03/07/2017 06:22 AM, Minchan Kim wrote: >>> Hello Johannes, >>> >>> On Mon, Mar 06, 2017 at 11:23:35AM +0100, Johannes Thumshirn wrote: zram can handle at

Re: [PATCH 0/13 v2] block: Fix block device shutdown related races

2017-03-07 Thread Jan Kara
On Mon 06-03-17 12:38:18, Omar Sandoval wrote: > On Wed, Mar 01, 2017 at 04:11:09PM +0100, Jan Kara wrote: > > On Tue 28-02-17 23:26:53, Omar Sandoval wrote: > > > On Tue, Feb 28, 2017 at 11:25:28PM -0800, Omar Sandoval wrote: > > > > On Wed, Feb 22, 2017 at 11:24:25AM +0100, Jan Kara wrote: > > >

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

2017-03-07 Thread Jan Kara
On Mon 06-03-17 09:25:42, James Bottomley wrote: > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote: > > On Mon 06-03-17 07:44:55, James Bottomley wrote: ... > > > > Sure. The call trace is: > > > > > > > > [ 41.919244] [ cut here ] > > > > [ 41.919263] WARNING: CPU:

Re: [PATCH 0/13 v2] block: Fix block device shutdown related races

2017-03-07 Thread Omar Sandoval
On Tue, Mar 07, 2017 at 02:57:30PM +0100, Jan Kara wrote: > On Mon 06-03-17 12:38:18, Omar Sandoval wrote: > > Unfortunately, this patch actually seems to have introduced a > > regression. Reverting the patch fixes it. > > > > I'm running a QEMU kvm vm with a virtio-scsi device and I get oopses >

[PATCH] don't forget to call pd_online_fn when activate policy

2017-03-07 Thread Zhou Chengming
From: z00354408 Signed-off-by: z00354408 --- block/blk-cgroup.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 8ba0af7..0dd9e76 100644 --- a/block/blk-cgroup.c +++

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

2017-03-07 Thread James Bottomley
On Tue, 2017-03-07 at 15:41 +0100, Jan Kara wrote: > On Mon 06-03-17 09:25:42, James Bottomley wrote: > > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote: > > > On Mon 06-03-17 07:44:55, James Bottomley wrote: > ... > > > > > Sure. The call trace is: > > > > > > > > > > [ 41.919244]

Re: [PATCH 02/11] block: Fix race of bdev open with gendisk shutdown

2017-03-07 Thread Tejun Heo
Hello, On Tue, Mar 07, 2017 at 12:14:20PM +0100, Jan Kara wrote: > > Given that this isn't a super hot path, I think it'd be far better to > > stick to a simpler synchronization mechanism. > > I'd be happy to do so however struct gendisk does not have any lock in it > and introducing a special