Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 12:44, Christian Borntraeger wrote: On 01/11/2018 10:13 AM, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM

[PATCH v3 1/2] block: fail op_is_write() requests to read-only partitions

Regular block device writes go through blkdev_write_iter(), which does bdev_read_only(), while zeroout/discard/etc requests are never checked, both userspace- and kernel-triggered. Add a generic catch-all check to generic_make_request_checks() to actually enforce ioctl(BLKROSET) and

[PATCH v3 0/2] block: enforce ioctl(BLKROSET) and set_disk_ro()

Hello, I was doing some cleanup work on rbd BLKROSET handler and discovered that we ignore partition rw/ro setting (hd_struct->policy) for pretty much everything but straight writes. David (CCed) has blktests patches standing by. (Another aspect of this is that we don't enforce open(2) mode.

[PATCH v3 2/2] block: add bdev_read_only() checks to common helpers

Similar to blkdev_write_iter(), return -EPERM if the partition is read-only. This covers ioctl(), fallocate() and most in-kernel users but isn't meant to be exhaustive -- everything else will be caught in generic_make_request_checks(), fail with -EIO and can be fixed later. Signed-off-by: Ilya

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 01/11/2018 10:13 AM, Ming Lei wrote: > On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: >> On 12/18/2017 02:56 PM, Stefan Haberland wrote: >>> On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: t

Re: blkdev loop UAF

Hi, On 2018/1/11 16:24, Dan Carpenter wrote: > Thanks for your report and the patch. I am sending it to the > linux-block devs since it's already public. > > regards, > dan carpenter The User-after-free problem is not specific for loop device, it can also be reproduced on scsi device, and

Re: blkdev loop UAF

Thanks for your report and the patch. I am sending it to the linux-block devs since it's already public. regards, dan carpenter On Thu, Jan 11, 2018 at 03:51:06PM +0800, Foy wrote: > BUG: > diff --git a/fs/block_dev.c b/fs/block_dev.c > index 4a181fc..db919a9 100644 > --- a/fs/block_dev.c > +++

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

> Il giorno 11 gen 2018, alle ore 10:30, Paolo Valente > ha scritto: > > > >> Il giorno 10 gen 2018, alle ore 05:58, Ming Lei ha >> scritto: >> >> Hi Paolo, >> >> Looks this one is introduced in recent merge, and it is triggered >> in test

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

> Il giorno 10 gen 2018, alle ore 05:58, Ming Lei ha > scritto: > > Hi Paolo, > > Looks this one is introduced in recent merge, and it is triggered > in test of IO vs. removing device on the latest for-next of block > tree: > > [ 296.151615] BUG: unable to handle

Re: scsi: memory leak in sg_start_req

On Thu, Jan 11, 2018 at 7:04 AM, Douglas Gilbert wrote: > On 2018-01-09 11:05 AM, Dmitry Vyukov wrote: >> >> Hello, >> >> syzkaller has found the following memory leak: >> >> unreferenced object 0x88004c19 (size 8328): >>comm "syz-executor", pid 4627, jiffies

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: > On 12/18/2017 02:56 PM, Stefan Haberland wrote: > > On 07.12.2017 00:29, Christoph Hellwig wrote: > >> On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: > >> t > commit

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 10:13, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: t > commit

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 2:56am -0500, Hannes Reinecke wrote: > Thinking of this a bit more, wouldn't it be better to modify add_disk() > (or, rather, device_add_disk()) to handle this case? > You already moved the call to 'blk_register_queue()' to the end of > device_add_disk(), so

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

On 1/11/18 2:41 AM, Paolo Valente wrote: > > >> Il giorno 11 gen 2018, alle ore 10:30, Paolo Valente >> ha scritto: >> >> >> >>> Il giorno 10 gen 2018, alle ore 05:58, Ming Lei ha >>> scritto: >>> >>> Hi Paolo, >>> >>> Looks this one is

Re: [PATCH v3 0/2] Rework blk_mq_mark_tag_wait()

On 1/10/18 2:41 PM, Bart Van Assche wrote: > Hello Jens, > > This patch series reworks the blk_mq_mark_tag_wait() implementation and also > fixes a race condition in that function. Please consider these two patches for > kernel v4.16. Applied 1/2 for now, need to mull over 2/2 a bit more. --

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 2:46am -0500, Hannes Reinecke wrote: > On 01/11/2018 03:12 AM, Mike Snitzer wrote: > > > > diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c > > index 870484eaed1f..2395122875b4 100644 > > --- a/block/blk-sysfs.c > > +++ b/block/blk-sysfs.c > > @@ -929,6

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, 2018-01-11 at 12:04 -0500, Mike Snitzer wrote: > So my v4, that I'll send out shortly, won't be using test_and_clear_bit() Please use queue_flag_set(), queue_flag_clear(), queue_flag_test_and_clear() and/or queue_flag_test_and_set() to manipulate queue flags. Thanks, Bart.

Re: [PATCH v2 2/2] blk-mq: Fix a race condition in blk_mq_mark_tag_wait()

On Thu, 2018-01-11 at 08:39 +0100, Hannes Reinecke wrote: > I'm actually not that convinced with this change; originally we had been > checking if it's on the wait list, and only _then_ call bt_wait_ptr(). > Now we call bt_wait_ptr() always, meaning we run a chance of increasing > the bitmap_tags

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 12:18pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 12:04 -0500, Mike Snitzer wrote: > > So my v4, that I'll send out shortly, won't be using test_and_clear_bit() > > Please use queue_flag_set(), queue_flag_clear(),

Re: scsi: memory leak in sg_start_req

On Thu, 2018-01-11 at 01:04 -0500, Douglas Gilbert wrote: > Monitoring that program with 'free' from another terminal I see > about 2.5 GBytes of ram "swallowed" almost immediately when the test > program runs. When the program exits (about 50 seconds later) as far > as I can see all that ram is

Re: blkdev loop UAF

On Thu 11-01-18 19:22:39, Hou Tao wrote: > Hi, > > On 2018/1/11 16:24, Dan Carpenter wrote: > > Thanks for your report and the patch. I am sending it to the > > linux-block devs since it's already public. > > > > regards, > > dan carpenter > > The User-after-free problem is not specific for

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

Thanks for looking into this Ming, I had missed it in the my current work overload. Can you send the updated series to Jens?

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, 2018-01-11 at 12:29 -0500, Mike Snitzer wrote: > On Thu, Jan 11 2018 at 12:18pm -0500, > Bart Van Assche wrote: > > > On Thu, 2018-01-11 at 12:04 -0500, Mike Snitzer wrote: > > > So my v4, that I'll send out shortly, won't be using test_and_clear_bit() > > > >

Re: [PATCH V3 4/5] blk-mq: return dispatch result to caller in blk_mq_try_issue_directly

On Thu, Jan 11 2018 at 1:01am -0500, Ming Lei wrote: > In the following patch, we will use blk_mq_try_issue_directly() for DM > to return the dispatch result, and DM need this informatin to improve > IO merge. > > Signed-off-by: Ming Lei Reviewed-by:

Re: [PATCH V3 5/5] blk-mq: issue request directly for blk_insert_cloned_request

On Thu, Jan 11 2018 at 1:01am -0500, Ming Lei wrote: > blk_insert_cloned_request() is called in fast path of dm-rq driver, and > in this function we append request to hctx->dispatch_list of the underlying > queue directly. > > 1) This way isn't efficient enough because

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11 2018 at 5:37pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > > Bart, if for some reason we regress for some workload you're able to > > more readily test we can deal with it. But I'm too encouraged by Ming's > >

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11 2018 at 1:01am -0500, Ming Lei wrote: > Hi Guys, > > The 1st patch removes the workaround of blk_mq_delay_run_hw_queue() in > case of requeue, this way isn't necessary, and more worse, it makes > BLK_MQ_S_SCHED_RESTART not working, and degarde I/O

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, 2018-01-11 at 17:58 -0500, Mike Snitzer wrote: > The changes are pretty easy to review. This notion that these changes > are problematic rings very hollow given your lack of actual numbers (or > some other concerning observation rooted in testing fact) to back up > your position. It's

Re: [PATCH V3 3/5] blk-mq: move actual issue into one helper

On Thu, Jan 11 2018 at 1:01am -0500, Ming Lei wrote: > No functional change, just to clean up code a bit, so that the following > change of using direct issue for blk_mq_request_bypass_insert() which is > needed by DM can be easier to do. > > Signed-off-by: Ming Lei

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > Bart, if for some reason we regress for some workload you're able to > more readily test we can deal with it. But I'm too encouraged by Ming's > performance improvements to hold these changes back any further. Sorry Mike but I think Ming's

Re: [PATCH v2 2/2] blk-mq: Fix a race condition in blk_mq_mark_tag_wait()

On Wed, Jan 10, 2018 at 11:39:19AM -0800, Bart Van Assche wrote: > Both add_wait_queue() and blk_mq_dispatch_wake() protect wait queue > manipulations with the wait queue lock. Hence also protect the > !list_empty(>entry) test with the wait queue lock instead of > the hctx lock. > >

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, 2018-01-11 at 14:20 -0500, Mike Snitzer wrote: > Yes, I noticed the use of sysfs_lock also. I've fixed it up earlier in > my v4 patchset and build on it. I'll add your Reported-by too. Hello Mike, There are many more inconsistencies with regard to queue flag manipulation in the block

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 12:47pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 12:29 -0500, Mike Snitzer wrote: > > On Thu, Jan 11 2018 at 12:18pm -0500, > > Bart Van Assche wrote: > > > > > On Thu, 2018-01-11 at 12:04 -0500, Mike Snitzer

Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 2:32pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 14:20 -0500, Mike Snitzer wrote: > > Yes, I noticed the use of sysfs_lock also. I've fixed it up earlier in > > my v4 patchset and build on it. I'll add your Reported-by too. > > Hello

[for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

blk_unregister_queue() must protect against any modifications of q->queue_flags (not just those performed in blk-sysfs.c). Therefore q->queue_lock needs to be used rather than q->sysfs_lock. Fixes: e9a823fb34a8b ("block: fix warning when I/O elevator is changed as request_queue is being

[for-4.16 PATCH v4 0/4] block/dm: allow DM to defer blk_register_queue() until ready

Hi Jens, I think this set is now ready for you to pick up for 4.16. Hannes, I ran with your review feedback and think the result is cleaner (avoids frivolously using another QUEUE_FLAG). Ming, I didn't add your Reviewed-by to "block: allow gendisk's request_queue registration to be deferred"

[for-4.16 PATCH v4 4/4] dm: fix awkward and incomplete request_queue initialization

DM is now no longer prone to having its request_queue be improperly initialized. Summary of changes: - defer DM's blk_register_queue() from add_disk()-time until dm_setup_md_queue() by using add_disk_no_queue_reg() in alloc_dev(). - dm_setup_md_queue() is updated to fully initialize DM's

[for-4.16 PATCH v4 1/4] block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN

device_add_disk() will only call bdi_register_owner() if !GENHD_FL_HIDDEN, so it follows that del_gendisk() should only call bdi_unregister() if !GENHD_FL_HIDDEN. Found with code inspection. bdi_unregister() won't do any harm if bdi_register_owner() wasn't used but best to avoid the unnecessary

[for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred

Since I can remember DM has forced the block layer to allow the allocation and initialization of the request_queue to be distinct operations. Reason for this is block/genhd.c:add_disk() has requires that the request_queue (and associated bdi) be tied to the gendisk before add_disk() is called --

Re: [for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred

On Thu, 2018-01-11 at 15:14 -0500, Mike Snitzer wrote: > -void device_add_disk(struct device *parent, struct gendisk *disk) > +void device_add_disk_no_queue_reg(struct device *parent, struct gendisk > *disk) > { > dev_t devt; > int retval; > @@ -682,7 +682,6 @@ void

Re: [for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11 2018 at 7:37pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 15:14 -0500, Mike Snitzer wrote: > > -void device_add_disk(struct device *parent, struct gendisk *disk) > > +void device_add_disk_no_queue_reg(struct device *parent, struct gendisk > >

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Thu, Jan 11 2018 at 7:28pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 15:14 -0500, Mike Snitzer wrote: > > blk_unregister_queue() must protect against any modifications of > > q->queue_flags (not just those performed in blk-sysfs.c). Therefore > >

[PATCH 1/2] genirq/affinity: assign vectors to all possible CPUs

From: Christoph Hellwig Currently we assign managed interrupt vectors to all present CPUs. This works fine for systems were we only online/offline CPUs. But in case of systems that support physical CPU hotplug (or the virtualized version of it) this means the additional CPUs

[PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

From: Christoph Hellwig The previous patch assigns interrupt vectors to all possible CPUs, so now hctx can be mapped to possible CPUs, this patch applies this fact to simplify queue mapping & schedule so that we don't need to handle CPU hotplug for dealing with physical CPU plug &

[PATCH 0/2] blk-mq: support physical CPU hotplug

Hi, This two patches support physical CPU hotplug, so that we can make blk-mq scale well when new physical CPU is added or removed, and this use case is normal for VM world. Also this patchset fixes the following warning reported by Christian Borntraeger:

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000436

On Thu, Jan 11, 2018 at 08:40:54AM -0700, Jens Axboe wrote: > On 1/11/18 2:41 AM, Paolo Valente wrote: > > > > > >> Il giorno 11 gen 2018, alle ore 10:30, Paolo Valente > >> ha scritto: > >> > >> > >> > >>> Il giorno 10 gen 2018, alle ore 05:58, Ming Lei

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Thu, 2018-01-11 at 15:14 -0500, Mike Snitzer wrote: > blk_unregister_queue() must protect against any modifications of > q->queue_flags (not just those performed in blk-sysfs.c). Therefore > q->queue_lock needs to be used rather than q->sysfs_lock. > > Fixes: e9a823fb34a8b ("block: fix

Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

> On Jan 10, 2018, at 9:38 PM, Abdul Haleem wrote: > > On Tue, 2018-01-09 at 18:09 +, Madhani, Himanshu wrote: >> Hello Abdul, >> >>> On Jan 9, 2018, at 7:54 AM, Bart Van Assche wrote: >>> >>> On Tue, 2018-01-09 at 14:44 +0530, Abdul

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11 2018 at 8:42pm -0500, Ming Lei wrote: > On Thu, Jan 11, 2018 at 10:37:37PM +, Bart Van Assche wrote: > > On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > > > Bart, if for some reason we regress for some workload you're able to > > > more readily

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Thu, Jan 11, 2018 at 06:46:54PM +0100, Christoph Hellwig wrote: > Thanks for looking into this Ming, I had missed it in the my current > work overload. Can you send the updated series to Jens? OK, I will post it out soon. Thanks, Ming

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11, 2018 at 08:57:21PM -0500, Mike Snitzer wrote: > On Thu, Jan 11 2018 at 8:42pm -0500, > Ming Lei wrote: > > > On Thu, Jan 11, 2018 at 10:37:37PM +, Bart Van Assche wrote: > > > On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > > > > Bart, if for

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11, 2018 at 10:37:37PM +, Bart Van Assche wrote: > On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > > Bart, if for some reason we regress for some workload you're able to > > more readily test we can deal with it. But I'm too encouraged by Ming's > > performance

Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

On Thu, Jan 11 2018 at 6:27pm -0500, Bart Van Assche wrote: > On Thu, 2018-01-11 at 17:58 -0500, Mike Snitzer wrote: > > The changes are pretty easy to review. This notion that these changes > > are problematic rings very hollow given your lack of actual numbers (or > >

Re: [for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred

On Thu, Jan 11, 2018 at 03:14:16PM -0500, Mike Snitzer wrote: > Since I can remember DM has forced the block layer to allow the > allocation and initialization of the request_queue to be distinct > operations. Reason for this is block/genhd.c:add_disk() has requires > that the request_queue (and

Re: [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue

On Thu, Jan 11, 2018 at 03:14:15PM -0500, Mike Snitzer wrote: > blk_unregister_queue() must protect against any modifications of > q->queue_flags (not just those performed in blk-sysfs.c). Therefore > q->queue_lock needs to be used rather than q->sysfs_lock. > > Fixes: e9a823fb34a8b ("block: fix

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte > ha scritto: > > > On 12/28/17 12:19, Paolo Valente wrote: > (snip half a tech report ;) > > So either this or the previous patch ("limit tags for writes and async I/O" > can lead to a hard,