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
> +++
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 4294749150 (age 45.507s)
>
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 11b2025c3326f7096ceb588c3117c7883850
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 11b2025c33
> 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 kernel NULL pointer derefer
> 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 of IO vs. removing device on the latest for-next
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 there
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
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
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. Te
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 Dr
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 +0
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 introduced in recent merge, and it is triggered
>>> in t
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 it would be tr
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 gi
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 loo
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.
--
Je
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 +930,9 @@ void b
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.
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 w
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(), queue_flag_test_and_clear()
> and/or
> queue_f
Thanks for looking into this Ming, I had missed it in the my current
work overload. Can you send the updated series to Jens?
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()
> >
> > Please use queue_flag_set()
Hello,
On Mon, Dec 18, 2017 at 04:15:10PM +, Josh Snyder wrote:
> Before commit e33a9bba85a8 ("sched/core: move IO scheduling accounting from
> io_schedule_timeout() into scheduler"), delayacct_blkio_end was called after
> context-switching into the task which completed I/O. This resulted in d
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(&wait->entry) test with the wait queue lock instead of
> the hctx lock.
>
> Signed-o
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 wrote:
> > > > So my v4, that I'll send out shortl
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 la
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 Mike,
>
> There are man
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 removed"
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" bec
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 reque
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
c
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 -- b
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 performance.
>
> The 2nd patch
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: Mike Snitzer
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
Reviewed-by: Mike Snitzer
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
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 hctx lock is always requi
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
> > performance improvements
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 not
> 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 Haleem wrote:
Greeting's,
Linux next
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 warning
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 device_add_disk(st
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
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 improvement
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
> > some other concerning ob
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 test we can deal with i
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
> > *disk)
> > {
> > dev_
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:
https://marc.info/?l=linux-block
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 & unplug. With th
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
> > q->queue_lock needs to be used ra
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 covered for in the
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 some reason we regress f
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 ha
> >>> scritto:
> >>>
> >>> Hi Paolo
> 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, unrecoverable hang with heavy writes. Sin
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
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 a
57 matches
Mail list logo