- revert an RDMA commit that didn't help but caused problems
- fix another minor P2P fallout
- make sure the multipath device inherits the devices limits of
the controllers below
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04
On 11/9/18 9:53 AM, jianchao.wang wrote:
> Hi Jens
>
> On 11/9/18 12:06 AM, Jens Axboe wrote:
>> DM currently uses atomic inc/dec to maintain a busy count of
>> IO on a given device. For the dm-mq path, we can replace this
>> with helper that just checks the state of the tags on the device.
>>
Hi Jens
On 11/9/18 12:06 AM, Jens Axboe wrote:
> DM currently uses atomic inc/dec to maintain a busy count of
> IO on a given device. For the dm-mq path, we can replace this
> with helper that just checks the state of the tags on the device.
>
> First patch is a prep patch that allows the
On Thu, 2018-11-08 at 10:50 -0700, Jens Axboe wrote:
> How about this incremental?
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 097e9a67d5f5..87bc5df72d48 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -248,7 +248,8 @@ static bool bt_iter(struct sbitmap
On 11/8/18 10:47 AM, Jens Axboe wrote:
> On 11/8/18 10:35 AM, Bart Van Assche wrote:
>> On Thu, 2018-11-08 at 09:31 -0700, Jens Axboe wrote:
>>> On 11/8/18 9:28 AM, Bart Van Assche wrote:
On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
> --- a/block/blk-mq-debugfs.c
> +++
On 11/8/18 10:35 AM, Bart Van Assche wrote:
> On Thu, 2018-11-08 at 09:31 -0700, Jens Axboe wrote:
>> On 11/8/18 9:28 AM, Bart Van Assche wrote:
>>> On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -424,13 +424,15 @@
On Thu, 2018-11-08 at 09:31 -0700, Jens Axboe wrote:
> On 11/8/18 9:28 AM, Bart Van Assche wrote:
> > On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
> > > --- a/block/blk-mq-debugfs.c
> > > +++ b/block/blk-mq-debugfs.c
> > > @@ -424,13 +424,15 @@ struct show_busy_params {
> > > * Note: the
On 11/8/18 9:30 AM, Bart Van Assche wrote:
> On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
>> +static bool blk_mq_check_busy(struct blk_mq_hw_ctx *hctx, struct request
>> *rq,
>> + void *priv, bool reserved)
>> +{
>> +/*
>> + * If we find a request, we know
On 11/8/18 9:28 AM, Bart Van Assche wrote:
> On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
>> --- a/block/blk-mq-debugfs.c
>> +++ b/block/blk-mq-debugfs.c
>> @@ -424,13 +424,15 @@ struct show_busy_params {
>> * Note: the state of a request may change while this function is in
>>
On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
> +static bool blk_mq_check_busy(struct blk_mq_hw_ctx *hctx, struct request *rq,
> + void *priv, bool reserved)
> +{
> + /*
> + * If we find a request, we know the queue is busy. Return false
> + * to stop
On Thu, 2018-11-08 at 09:06 -0700, Jens Axboe wrote:
> --- a/block/blk-mq-debugfs.c
> +++ b/block/blk-mq-debugfs.c
> @@ -424,13 +424,15 @@ struct show_busy_params {
> * Note: the state of a request may change while this function is in
> progress,
> * e.g. due to a concurrent
Returns true if the queue currently has requests pending,
false if not.
DM can use this to replace the atomic_inc/dec they do per device
to see if a device is busy.
Reviewed-by: Mike Snitzer
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 26 ++
We have this functionality in sbitmap, but we don't export it in
blk-mq for users of the tags busy iteration. This can be useful
for stopping the iteration, if the caller doesn't need to find
more requests.
Reviewed-by: Mike Snitzer
Signed-off-by: Jens Axboe
---
block/blk-mq-debugfs.c | 4
Returns true if the queue currently has requests pending,
false if not.
DM can use this to replace the atomic_inc/dec they do per device
to see if a device is busy.
Cc: Mike Snitzer
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 22 ++
include/linux/blk-mq.h | 2
DM currently uses atomic inc/dec to maintain a busy count of
IO on a given device. For the dm-mq path, we can replace this
with helper that just checks the state of the tags on the device.
First patch is a prep patch that allows the iteration helpers
to return true/false, like we support
On 11/8/18 8:54 AM, Laurence Oberman wrote:
> On Thu, 2018-11-08 at 08:42 -0700, Jens Axboe wrote:
>> +static bool blk_mq_check_busy(struct blk_mq_hw_ctx *hctx, struct
>> request *rq,
>> + void *priv, bool reserved)
>> +{
>> + bool *busy = (bool *) priv;
>> +
>> +
On Thu, 2018-11-08 at 08:42 -0700, Jens Axboe wrote:
> +static bool blk_mq_check_busy(struct blk_mq_hw_ctx *hctx, struct
> request *rq,
> + void *priv, bool reserved)
> +{
> + bool *busy = (bool *) priv;
> +
> + /*
> + * If we find a request, we know
On Thu, Nov 08 2018 at 10:42am -0500,
Jens Axboe wrote:
> Returns true if the queue currently has requests pending,
> false if not.
>
> DM can use this to replace the atomic_inc/dec they do per device
> to see if a device is busy.
>
> Cc: Mike Snitzer
> Signed-off-by: Jens Axboe
On Thu, Nov 08 2018 at 10:42am -0500,
Jens Axboe wrote:
> We have this functionality in sbitmap, but we don't export it in
> blk-mq for users of the tags busy iteration. This can be useful
> for stopping the iteration, if the caller doesn't need to find
> more requests.
>
> Cc: Mike Snitzer
>
Returns true if the queue currently has requests pending,
false if not.
DM can use this to replace the atomic_inc/dec they do per device
to see if a device is busy.
Cc: Mike Snitzer
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 22 ++
include/linux/blk-mq.h | 2
DM currently uses atomic inc/dec to maintain a busy count of
IO on a given device. For the dm-mq path, we can replace this
with helper that just checks the state of the tags on the device.
First patch is a prep patch that allows the iteration helpers
to return true/false, like we support
We have this functionality in sbitmap, but we don't export it in
blk-mq for users of the tags busy iteration. This can be useful
for stopping the iteration, if the caller doesn't need to find
more requests.
Cc: Mike Snitzer
Signed-off-by: Jens Axboe
---
block/blk-mq-debugfs.c | 4 +++-
On Thu, Nov 08, 2018 at 07:10:58PM +0800, Ming Lei wrote:
> I guess the issue may depend on specific QEMU version, just tried the test
> over
> virtio-scsi/sata/usb-storage emulated via qemu-2.10.2-1.fc27, not observed
> this problem.
I actually didn't use virtio-scsi, but it really doesn't
On 11/8/18 6:25 AM, Jan Kara wrote:
> On Thu 08-11-18 06:21:21, Jens Axboe wrote:
>> On 11/8/18 6:01 AM, Jan Kara wrote:
>>> Hi,
>>>
>>> this patch series fixes oops and possible deadlocks as reported by syzbot
>>> [1]
>>> [2]. The second patch in the series (from Tetsuo) fixes the oops, the
>>>
On Thu 08-11-18 06:21:21, Jens Axboe wrote:
> On 11/8/18 6:01 AM, Jan Kara wrote:
> > Hi,
> >
> > this patch series fixes oops and possible deadlocks as reported by syzbot
> > [1]
> > [2]. The second patch in the series (from Tetsuo) fixes the oops, the
> > remaining
> > patches are cleaning up
On 11/8/18 6:01 AM, Jan Kara wrote:
> Hi,
>
> this patch series fixes oops and possible deadlocks as reported by syzbot [1]
> [2]. The second patch in the series (from Tetsuo) fixes the oops, the
> remaining
> patches are cleaning up the locking in the loop driver so that we can in the
> end
Move setting of lo_state to Lo_rundown out into the callers. That will
allow us to unlock loop_ctl_mutex while the loop device is protected
from other changes by its special state.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 52 +++-
1 file
The nested acquisition of loop_ctl_mutex (->lo_ctl_mutex back then) has
been introduced by commit f028f3b2f987e "loop: fix circular locking in
loop_clr_fd()" to fix lockdep complains about bd_mutex being acquired
after lo_ctl_mutex during partition rereading. Now that these are
properly fixed,
Push loop_ctl_mutex down to loop_change_fd(). We will need this to be
able to call loop_reread_partitions() without loop_ctl_mutex.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/block/loop.c
Push loop_ctl_mutex down to loop_set_status(). We will need this to be
able to call loop_reread_partitions() without loop_ctl_mutex.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 51 +--
1 file changed, 25 insertions(+), 26 deletions(-)
diff
Calling loop_reread_partitions() under loop_ctl_mutex causes lockdep to
complain about circular lock dependency between bdev->bd_mutex and
lo->lo_ctl_mutex. The problem is that on loop device open or close
lo_open() and lo_release() get called with bdev->bd_mutex held and they
need to acquire
Calling blkdev_reread_part() under loop_ctl_mutex causes lockdep to
complain about circular lock dependency between bdev->bd_mutex and
lo->lo_ctl_mutex. The problem is that on loop device open or close
lo_open() and lo_release() get called with bdev->bd_mutex held and they
need to acquire
Push loop_ctl_mutex down to loop_get_status() to avoid the unusual
convention that the function gets called with loop_ctl_mutex held and
releases it.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 37 ++---
1 file changed, 10 insertions(+), 27 deletions(-)
loop_clr_fd() has a weird locking convention that is expects
loop_ctl_mutex held, releases it on success and keeps it on failure.
Untangle the mess by moving locking of loop_ctl_mutex into
loop_clr_fd().
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 49
From: Tetsuo Handa
vfs_getattr() needs "struct path" rather than "struct file".
Let's use path_get()/path_put() rather than get_file()/fput().
Signed-off-by: Tetsuo Handa
Reviewed-by: Jan Kara
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 10 +-
1 file changed, 5 insertions(+),
Code in loop_change_fd() drops reference to the old file (and also the
new file in a failure case) under loop_ctl_mutex. Similarly to a
situation in loop_set_fd() this can create a circular locking dependency
if this was the last reference holding the file open. Delay dropping of
the file
Push acquisition of lo_ctl_mutex down into individual ioctl handling
branches. This is a preparatory step for pushing the lock down into
individual ioctl handling functions so that they can release the lock as
they need it. We also factor out some simple ioctl handlers that will
not need any
Now that loop_ctl_mutex is global, just get rid of loop_index_mutex as
there is no good reason to keep these two separate and it just
complicates the locking.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 41 -
1 file changed, 20 insertions(+), 21
Hi,
this patch series fixes oops and possible deadlocks as reported by syzbot [1]
[2]. The second patch in the series (from Tetsuo) fixes the oops, the remaining
patches are cleaning up the locking in the loop driver so that we can in the
end reasonably easily switch to rereading partitions
From: Tetsuo Handa
syzbot is reporting NULL pointer dereference [1] which is caused by
race condition between ioctl(loop_fd, LOOP_CLR_FD, 0) versus
ioctl(other_loop_fd, LOOP_SET_FD, loop_fd) due to traversing other
loop devices at loop_validate_file() without holding corresponding
The call of __blkdev_reread_part() from loop_reread_partition() happens
only when we need to invalidate partitions from loop_release(). Thus
move a detection for this into loop_clr_fd() and simplify
loop_reread_partition().
This makes loop_reread_partition() safe to use without loop_ctl_mutex
Push lo_ctl_mutex down to loop_set_fd(). We will need this to be able to
call loop_reread_partitions() without lo_ctl_mutex.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/block/loop.c
__loop_release() has a single call site. Fold it there. This is
currently not a huge win but it will make following replacement of
loop_index_mutex more obvious.
Signed-off-by: Jan Kara
---
drivers/block/loop.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git
On Thu, Nov 8, 2018 at 6:07 PM Johannes Thumshirn wrote:
>
> On 08/11/2018 02:22, Keith Busch wrote:
> > $ ./sg-test /dev/sda | grep -v 0
> > 40733f4019db8001244019db4065244019db0094244019db
> >
On 08/11/2018 02:22, Keith Busch wrote:
> $ ./sg-test /dev/sda | grep -v 0
> 40733f4019db8001244019db4065244019db0094244019db
> c025244019dbc0e43a4019db40973a4019dbc0623a4019db
>
45 matches
Mail list logo
