2019-05-24 12:03:47 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-18 14:27:13 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-25 05:47:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-07-23 16:24:27 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-08 15:59:53 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-02 14:28:52 +02:00
|
|
|
|
2006-01-06 00:09:47 -08:00
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
2006-01-06 00:09:47 -08:00
|
|
|
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-11-12 18:10:39 -08:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
2015-04-02 10:11:37 +02:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-24 11:46:01 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-04-26 11:49:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-22 15:09:53 -05:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
2016-09-08 12:33:39 -07:00
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-08-17 08:20:09 +02:00
|
|
|
|
2016-09-08 12:33:39 -07:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2015-04-02 10:11:37 +02:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-02 10:11:35 +02:00
|
|
|
|
|
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
|
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2021-09-16 17:33:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2019-05-29 15:16:05 -05:00
|
|
|
|
2006-07-01 04:36:36 -07:00
|
|
|
|
2017-08-14 18:56:16 +00:00
|
|
|
|
2026-08-05 20:29:30 +08:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-30 11:41:45 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nbd: support FLUSH requests
Currently, the NBD device does not accept flush requests from the Linux
block layer. If the NBD server opened the target with neither O_SYNC nor
O_DSYNC, however, the device will be effectively backed by a writeback
cache. Without issuing flushes properly, operation of the NBD device will
not be safe against power losses.
The NBD protocol has support for both a cache flush command and a FUA
command flag; the server will also pass a flag to note its support for
these features. This patch adds support for the cache flush command and
flag. In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl,
and map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush. When the
flag is active the block layer will send REQ_FLUSH requests, which we
translate to NBD_CMD_FLUSH commands.
FUA support is not included in this patch because all free software
servers implement it with a full fdatasync; thus it has no advantage over
supporting flush only. Because I [Paolo] cannot really benchmark it in a
realistic scenario, I cannot tell if it is a good idea or not. It is also
not clear if it is valid for an NBD server to support FUA but not flush.
The Linux block layer gives a warning for this combination, the NBD
protocol documentation says nothing about it.
The patch also fixes a small problem in the handling of flags: nbd->flags
must be cleared at the end of NBD_DO_IT, but the driver was not doing
that. The bug manifests itself as follows. Suppose you two different
client/server pairs to start the NBD device. Suppose also that the first
client supports NBD_SET_FLAGS, and the first server sends
NBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two
things. Before this patch, the second invocation of NBD_DO_IT will use a
stale value of nbd->flags, and the second server will issue an error every
time it receives an NBD_CMD_FLUSH command.
This bug is pre-existing, but it becomes much more important after this
patch; flush failures make the device pretty much unusable, unlike
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:05:23 -08:00
|
|
|
|
2012-10-04 17:16:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:10 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2017-08-21 17:13:08 +05:30
|
|
|
|
2018-05-24 13:38:59 -06:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:10 -07:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-16 14:51:17 -04:00
|
|
|
|
2021-08-11 14:44:25 +02:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:24 +02:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
2021-08-11 14:44:24 +02:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
|
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
2023-11-07 18:34:35 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:24 +02:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
2021-08-11 14:44:24 +02:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-05 10:51:39 +02:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2018-05-30 10:45:11 -06:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-05-30 10:45:11 -06:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-05-30 10:45:11 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 06:47:16 +01:00
|
|
|
|
2015-07-27 07:36:49 +02:00
|
|
|
|
2024-02-29 06:38:46 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2021-10-26 22:40:13 +08:00
|
|
|
|
|
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
|
|
|
|
|
2023-02-06 22:58:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 15:56:59 +01:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2020-11-16 15:56:59 +01:00
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2018-05-16 14:51:19 -04:00
|
|
|
|
2024-02-29 06:38:46 -08:00
|
|
|
|
2026-08-05 20:29:25 +08:00
|
|
|
|
2024-02-29 06:38:46 -08:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-29 06:38:46 -08:00
|
|
|
|
|
|
|
|
|
2020-11-16 15:56:58 +01:00
|
|
|
|
2020-12-17 00:58:47 -08:00
|
|
|
|
|
|
|
|
|
2020-11-16 15:57:01 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2015-07-27 07:36:49 +02:00
|
|
|
|
|
|
|
|
|
2017-04-20 16:03:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-20 16:03:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-06-04 10:40:12 -06:00
|
|
|
|
2017-04-20 16:03:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-20 16:03:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-04-02 10:11:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:01 +02:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2016-09-08 12:33:38 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-08-17 08:20:02 +02:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-12 15:20:37 +02:00
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
2023-11-17 00:23:16 +08:00
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-06 20:03:51 +08:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2016-09-08 12:33:40 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2019-10-21 15:56:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:46 +08:00
|
|
|
|
2021-09-16 17:33:45 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2022-05-21 15:37:46 +08:00
|
|
|
|
2019-10-21 15:56:27 -04:00
|
|
|
|
2018-05-29 15:52:31 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2020-02-28 01:40:29 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2018-05-30 10:45:11 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2020-02-28 01:40:29 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2020-02-28 01:40:29 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2024-08-30 11:41:45 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2018-05-29 15:52:29 +02:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-28 01:40:30 -05:00
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-28 01:40:30 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2022-05-21 15:37:46 +08:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2018-05-29 15:52:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2024-01-12 13:26:57 +00:00
|
|
|
|
2017-05-08 15:59:53 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-02 13:04:47 -07:00
|
|
|
|
2016-12-05 16:20:29 -05:00
|
|
|
|
2011-08-19 14:48:22 +02:00
|
|
|
|
|
|
|
|
|
2008-04-02 13:04:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-12 05:09:35 -05:00
|
|
|
|
2015-11-12 04:51:19 -05:00
|
|
|
|
2017-05-08 15:59:53 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-11-03 00:12:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-11-03 00:12:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-05-08 15:59:53 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-24 15:57:18 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2017-01-19 16:08:49 -05:00
|
|
|
|
2015-11-12 05:09:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2015-04-17 22:37:21 +02:00
|
|
|
|
2017-05-25 23:55:54 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2015-04-17 22:37:21 +02:00
|
|
|
|
2024-05-10 13:23:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2015-11-12 05:09:35 -05:00
|
|
|
|
2019-08-13 11:39:50 -05:00
|
|
|
|
|
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-01-31 16:57:28 +01:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-01-31 16:57:28 +01:00
|
|
|
|
|
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2017-01-31 16:57:28 +01:00
|
|
|
|
|
|
|
|
|
2017-05-25 23:55:54 -04:00
|
|
|
|
|
|
|
|
|
2024-08-12 15:20:37 +02:00
|
|
|
|
|
|
|
|
|
2017-05-25 23:55:54 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 11:49:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
2017-05-25 23:55:54 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
nbd: support FLUSH requests
Currently, the NBD device does not accept flush requests from the Linux
block layer. If the NBD server opened the target with neither O_SYNC nor
O_DSYNC, however, the device will be effectively backed by a writeback
cache. Without issuing flushes properly, operation of the NBD device will
not be safe against power losses.
The NBD protocol has support for both a cache flush command and a FUA
command flag; the server will also pass a flag to note its support for
these features. This patch adds support for the cache flush command and
flag. In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl,
and map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush. When the
flag is active the block layer will send REQ_FLUSH requests, which we
translate to NBD_CMD_FLUSH commands.
FUA support is not included in this patch because all free software
servers implement it with a full fdatasync; thus it has no advantage over
supporting flush only. Because I [Paolo] cannot really benchmark it in a
realistic scenario, I cannot tell if it is a good idea or not. It is also
not clear if it is valid for an NBD server to support FUA but not flush.
The Linux block layer gives a warning for this combination, the NBD
protocol documentation says nothing about it.
The patch also fixes a small problem in the handling of flags: nbd->flags
must be cleared at the end of NBD_DO_IT, but the driver was not doing
that. The bug manifests itself as follows. Suppose you two different
client/server pairs to start the NBD device. Suppose also that the first
client supports NBD_SET_FLAGS, and the first server sends
NBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two
things. Before this patch, the second invocation of NBD_DO_IT will use a
stale value of nbd->flags, and the second server will issue an error every
time it receives an NBD_CMD_FLUSH command.
This bug is pre-existing, but it becomes much more important after this
patch; flush failures make the device pretty much unusable, unlike
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:05:23 -08:00
|
|
|
|
2024-05-10 13:23:12 -07:00
|
|
|
|
nbd: support FLUSH requests
Currently, the NBD device does not accept flush requests from the Linux
block layer. If the NBD server opened the target with neither O_SYNC nor
O_DSYNC, however, the device will be effectively backed by a writeback
cache. Without issuing flushes properly, operation of the NBD device will
not be safe against power losses.
The NBD protocol has support for both a cache flush command and a FUA
command flag; the server will also pass a flag to note its support for
these features. This patch adds support for the cache flush command and
flag. In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl,
and map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush. When the
flag is active the block layer will send REQ_FLUSH requests, which we
translate to NBD_CMD_FLUSH commands.
FUA support is not included in this patch because all free software
servers implement it with a full fdatasync; thus it has no advantage over
supporting flush only. Because I [Paolo] cannot really benchmark it in a
realistic scenario, I cannot tell if it is a good idea or not. It is also
not clear if it is valid for an NBD server to support FUA but not flush.
The Linux block layer gives a warning for this combination, the NBD
protocol documentation says nothing about it.
The patch also fixes a small problem in the handling of flags: nbd->flags
must be cleared at the end of NBD_DO_IT, but the driver was not doing
that. The bug manifests itself as follows. Suppose you two different
client/server pairs to start the NBD device. Suppose also that the first
client supports NBD_SET_FLAGS, and the first server sends
NBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two
things. Before this patch, the second invocation of NBD_DO_IT will use a
stale value of nbd->flags, and the second server will issue an error every
time it receives an NBD_CMD_FLUSH command.
This bug is pre-existing, but it becomes much more important after this
patch; flush failures make the device pretty much unusable, unlike
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Acked-by: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:05:23 -08:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
block nbd: use req.cookie instead of req.handle
The NBD spec was recently changed [1] to refer to the opaque client
identifier as a 'cookie' rather than a 'handle', but has for a much
longer time listed it as a 64-bit value, and declares that all values
in the NBD protocol are sent in network byte order (big-endian).
Because the value is opaque to the server, it doesn't usually matter
what endianness we send as the client - as long as we are consistent
that either we byte-swap on both write and read, or on neither, then
we can match server replies back to our requests. That said, our
internal use of the cookie is as a 64-bit number (well, as two 32-bit
numbers concatenated together), rather than as 8 individual bytes; so
prior to this commit, we ARE leaking the native endianness of our
internals as a client out to the server. We don't know of any server
that will actually inspect the opaque value and behave differently
depending on whether a little-endian or big-endian client is sending
requests, but since we DO log the cookie value, a wireshark capture of
the network traffic is easier to correlate back to the kernel traffic
of a big-endian host (where the u64 and char[8] representations are
the same) than of a little-endian host (where if wireshark honors the
NBD spec and displays a u64 in network byte order, it is byte-swapped
from what the kernel logged).
The fix in this patch is thus two-part: it now consistently uses
network byte order for the opaque value (no difference to a big-endian
machine, but an extra byteswap on a little-endian machine; probably in
the noise compared to the overhead of network traffic in general), and
now uses a 64-bit integer instead of char[8] as its preferred access
to the opaque value (direct assignment instead of memcpy()).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20230410180611.1051618-4-eblake@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-10 13:06:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-04-26 11:49:48 -07:00
|
|
|
|
|
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2018-06-04 10:40:12 -06:00
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2015-11-12 05:09:35 -05:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2019-04-26 11:49:49 -07:00
|
|
|
|
2021-09-16 17:33:48 +08:00
|
|
|
|
2017-10-24 15:57:18 -04:00
|
|
|
|
block nbd: use req.cookie instead of req.handle
The NBD spec was recently changed [1] to refer to the opaque client
identifier as a 'cookie' rather than a 'handle', but has for a much
longer time listed it as a 64-bit value, and declares that all values
in the NBD protocol are sent in network byte order (big-endian).
Because the value is opaque to the server, it doesn't usually matter
what endianness we send as the client - as long as we are consistent
that either we byte-swap on both write and read, or on neither, then
we can match server replies back to our requests. That said, our
internal use of the cookie is as a 64-bit number (well, as two 32-bit
numbers concatenated together), rather than as 8 individual bytes; so
prior to this commit, we ARE leaking the native endianness of our
internals as a client out to the server. We don't know of any server
that will actually inspect the opaque value and behave differently
depending on whether a little-endian or big-endian client is sending
requests, but since we DO log the cookie value, a wireshark capture of
the network traffic is easier to correlate back to the kernel traffic
of a big-endian host (where the u64 and char[8] representations are
the same) than of a little-endian host (where if wireshark honors the
NBD spec and displays a u64 in network byte order, it is byte-swapped
from what the kernel logged).
The fix in this patch is thus two-part: it now consistently uses
network byte order for the opaque value (no difference to a big-endian
machine, but an extra byteswap on a little-endian machine; probably in
the noise compared to the overhead of network traffic in general), and
now uses a 64-bit integer instead of char[8] as its preferred access
to the opaque value (direct assignment instead of memcpy()).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20230410180611.1051618-4-eblake@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-10 13:06:10 -05:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2016-12-05 16:20:29 -05:00
|
|
|
|
2011-08-19 14:48:22 +02:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 17:19:00 -08:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-19 16:08:49 -05:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2018-06-04 10:40:12 -06:00
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-16 17:33:48 +08:00
|
|
|
|
2017-10-24 15:57:18 -04:00
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2011-08-19 14:48:22 +02:00
|
|
|
|
|
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2007-08-16 13:43:12 +02:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-17 12:30:37 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2019-04-26 11:49:49 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
block nbd: use req.cookie instead of req.handle
The NBD spec was recently changed [1] to refer to the opaque client
identifier as a 'cookie' rather than a 'handle', but has for a much
longer time listed it as a 64-bit value, and declares that all values
in the NBD protocol are sent in network byte order (big-endian).
Because the value is opaque to the server, it doesn't usually matter
what endianness we send as the client - as long as we are consistent
that either we byte-swap on both write and read, or on neither, then
we can match server replies back to our requests. That said, our
internal use of the cookie is as a 64-bit number (well, as two 32-bit
numbers concatenated together), rather than as 8 individual bytes; so
prior to this commit, we ARE leaking the native endianness of our
internals as a client out to the server. We don't know of any server
that will actually inspect the opaque value and behave differently
depending on whether a little-endian or big-endian client is sending
requests, but since we DO log the cookie value, a wireshark capture of
the network traffic is easier to correlate back to the kernel traffic
of a big-endian host (where the u64 and char[8] representations are
the same) than of a little-endian host (where if wireshark honors the
NBD spec and displays a u64 in network byte order, it is byte-swapped
from what the kernel logged).
The fix in this patch is thus two-part: it now consistently uses
network byte order for the opaque value (no difference to a big-endian
machine, but an extra byteswap on a little-endian machine; probably in
the noise compared to the overhead of network traffic in general), and
now uses a 64-bit integer instead of char[8] as its preferred access
to the opaque value (direct assignment instead of memcpy()).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20230410180611.1051618-4-eblake@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-04-10 13:06:10 -05:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-04-26 11:49:49 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:46 +08:00
|
|
|
|
2021-09-16 17:33:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-16 17:33:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-01 17:25:38 +08:00
|
|
|
|
|
|
|
|
|
2021-09-16 17:33:46 +08:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-21 15:56:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-06-04 10:40:12 -06:00
|
|
|
|
2015-04-17 22:37:21 +02:00
|
|
|
|
2007-09-25 12:35:59 +02:00
|
|
|
|
2013-11-23 17:19:00 -08:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
2007-09-25 12:35:59 +02:00
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2021-09-16 17:33:48 +08:00
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2011-08-19 14:48:22 +02:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2020-02-28 01:40:29 -05:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
2007-08-16 13:43:12 +02:00
|
|
|
|
2015-04-02 10:11:38 +02:00
|
|
|
|
2018-06-04 10:40:12 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2019-04-26 11:49:49 -07:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2021-09-16 22:18:10 +08:00
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2020-06-11 08:44:47 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-17 08:20:03 +02:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
|
|
|
|
|
2021-09-16 22:18:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:03 +02:00
|
|
|
|
2021-09-16 22:18:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-11 08:44:47 +02:00
|
|
|
|
2022-05-21 15:37:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-16 22:18:10 +08:00
|
|
|
|
2015-08-17 08:20:03 +02:00
|
|
|
|
2021-09-16 17:33:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2025-11-08 15:02:02 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-07-06 20:03:53 +08:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2018-05-30 18:51:00 +02:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2021-08-13 23:13:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-21 15:56:27 -04:00
|
|
|
|
2021-09-16 17:33:45 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2019-10-21 15:56:27 -04:00
|
|
|
|
|
|
|
|
|
2017-04-20 16:03:09 +02:00
|
|
|
|
2018-11-08 10:24:07 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-07-04 09:57:09 +03:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2017-07-04 09:57:09 +03:00
|
|
|
|
2015-08-17 08:20:04 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2026-08-05 20:29:23 +08:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:23 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:23 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:23 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-22 16:06:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2022-03-22 16:06:39 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2024-05-10 13:23:11 -07:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-05 16:20:29 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-06-03 09:38:04 +02:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-06 16:11:58 -05:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2024-06-04 16:15:31 -06:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:05 +02:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2024-05-10 13:23:13 -07:00
|
|
|
|
2008-04-29 01:02:46 -07:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-10-02 16:22:08 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2019-10-17 16:27:34 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-09 13:22:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-17 16:27:34 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-19 14:09:11 +08:00
|
|
|
|
2019-10-17 16:27:34 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-13 04:26:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-22 05:22:55 +05:30
|
|
|
|
2026-06-13 04:26:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2023-02-06 22:58:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-17 16:27:34 -05:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2026-06-13 04:26:19 +00:00
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2020-06-29 09:23:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2020-06-29 09:23:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:01:56 -04:00
|
|
|
|
2020-06-29 09:23:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:56 -04:00
|
|
|
|
2019-09-23 15:09:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:57 -04:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2024-10-29 09:19:41 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2020-06-29 09:23:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-17 16:27:34 -05:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-21 10:48:15 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-07-25 13:31:19 -04:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
2022-03-30 07:29:03 +02:00
|
|
|
|
2015-10-29 12:04:51 +01:00
|
|
|
|
2022-03-30 07:29:06 +02:00
|
|
|
|
2017-03-24 14:08:29 -04:00
|
|
|
|
2022-03-30 07:29:03 +02:00
|
|
|
|
2015-10-29 12:04:51 +01:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2015-10-29 12:06:15 +01:00
|
|
|
|
2024-06-17 08:04:37 +02:00
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-29 12:06:15 +01:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-11-12 05:09:35 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-07-21 10:48:14 -04:00
|
|
|
|
|
|
|
|
|
2022-09-15 20:25:47 -04:00
|
|
|
|
2017-07-21 10:48:14 -04:00
|
|
|
|
2017-03-24 14:08:26 -04:00
|
|
|
|
2021-09-16 17:33:48 +08:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
2017-07-21 10:48:14 -04:00
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
2017-07-21 10:48:13 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:25 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2021-09-22 20:37:11 +08:00
|
|
|
|
2026-08-05 20:29:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-22 20:37:11 +08:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-23 17:49:55 +02:00
|
|
|
|
2017-05-23 17:49:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
2025-07-09 19:17:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2020-01-22 11:18:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-21 10:48:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-11 10:33:08 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2022-03-30 07:29:03 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-21 09:19:45 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
syzbot reported hung task [1]. The following program is a simplified
version of the reproducer:
int main(void)
{
int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}
When signal interrupt nbd_start_device_ioctl() waiting the condition
atomic_read(&config->recv_threads) == 0, the task can hung because it
waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when
signal interrupt nbd_start_device_ioctl().
Link: https://syzkaller.appspot.com/bug?id=7d89a3ffacd2b83fdd39549bc4d8e0a89ef21239 [1]
Reported-by: syzbot+38e6c55d4969a14c1534@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20220907163502.577561-1-syoshida@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-08 01:35:02 +09:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
syzbot reported hung task [1]. The following program is a simplified
version of the reproducer:
int main(void)
{
int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}
When signal interrupt nbd_start_device_ioctl() waiting the condition
atomic_read(&config->recv_threads) == 0, the task can hung because it
waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when
signal interrupt nbd_start_device_ioctl().
Link: https://syzkaller.appspot.com/bug?id=7d89a3ffacd2b83fdd39549bc4d8e0a89ef21239 [1]
Reported-by: syzbot+38e6c55d4969a14c1534@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20220907163502.577561-1-syoshida@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-08 01:35:02 +09:00
|
|
|
|
|
|
|
|
|
2019-12-08 16:51:50 -06:00
|
|
|
|
nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
syzbot reported hung task [1]. The following program is a simplified
version of the reproducer:
int main(void)
{
int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}
When signal interrupt nbd_start_device_ioctl() waiting the condition
atomic_read(&config->recv_threads) == 0, the task can hung because it
waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when
signal interrupt nbd_start_device_ioctl().
Link: https://syzkaller.appspot.com/bug?id=7d89a3ffacd2b83fdd39549bc4d8e0a89ef21239 [1]
Reported-by: syzbot+38e6c55d4969a14c1534@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20220907163502.577561-1-syoshida@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-08 01:35:02 +09:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2022-03-30 07:29:03 +02:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
2023-08-11 12:08:18 +02:00
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2022-05-21 15:37:47 +08:00
|
|
|
|
2023-10-03 17:31:06 +02:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
|
|
|
|
|
2020-08-10 08:00:44 -04:00
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:49 -05:00
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2021-08-04 10:12:12 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2015-10-29 11:51:16 +01:00
|
|
|
|
2023-08-11 12:08:18 +02:00
|
|
|
|
2017-04-06 17:01:59 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2015-07-27 07:36:49 +02:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2021-08-04 10:12:12 +08:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2019-08-13 11:39:52 -05:00
|
|
|
|
2007-10-16 23:27:37 -07:00
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
2012-10-04 17:16:15 -07:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2012-10-04 17:16:15 -07:00
|
|
|
|
2017-02-07 17:10:22 -05:00
|
|
|
|
2022-03-30 07:29:03 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 00:09:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:55 +02:00
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
|
|
|
|
|
2012-03-28 14:42:51 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-05 22:25:18 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 14:04:40 -05:00
|
|
|
|
2009-04-02 16:58:41 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2023-11-17 00:23:16 +08:00
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2023-11-17 00:23:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:55 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:36 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2020-12-17 00:58:47 -08:00
|
|
|
|
2023-06-08 13:02:36 +02:00
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
2020-12-17 00:58:47 -08:00
|
|
|
|
2023-06-08 13:02:36 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 13:02:37 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2022-03-30 07:29:06 +02:00
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2023-11-07 18:34:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 17:01:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
|
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
2016-01-07 10:04:37 -05:00
|
|
|
|
2023-11-07 18:34:35 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 15:10:55 +08:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 23:55:54 -04:00
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
2024-08-12 15:20:37 +02:00
|
|
|
|
|
|
|
|
|
2024-08-12 15:20:40 +02:00
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 15:10:55 +08:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-10-24 21:15:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
2023-05-12 17:05:32 +04:00
|
|
|
|
2015-10-24 21:15:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
2021-02-06 15:10:55 +08:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2016-09-08 12:33:40 -07:00
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2021-02-06 15:10:55 +08:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-12 17:05:32 +04:00
|
|
|
|
2015-10-24 21:15:34 +02:00
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-01 10:19:08 -06:00
|
|
|
|
2026-05-23 12:52:35 +00:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2017-05-01 10:19:08 -06:00
|
|
|
|
2018-07-16 12:11:34 -04:00
|
|
|
|
2018-07-16 12:11:35 -04:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 13:39:16 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2017-04-20 16:03:06 +02:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
2016-09-08 12:33:40 -07:00
|
|
|
|
2016-09-08 12:33:37 -07:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:29 +08:00
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2024-02-15 08:02:48 +01:00
|
|
|
|
|
|
|
|
|
2024-05-31 09:47:59 +02:00
|
|
|
|
2024-02-15 08:02:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
2026-08-05 20:29:29 +08:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-19 07:01:59 +01:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:28 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-05 20:21:59 +08:00
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:06 +02:00
|
|
|
|
2021-08-11 14:44:28 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
2024-02-15 08:02:48 +01:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2017-04-06 17:01:58 -04:00
|
|
|
|
2021-08-25 18:31:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2022-04-02 11:40:23 -06:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-27 14:59:58 -07:00
|
|
|
|
|
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
2021-08-25 18:31:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
2021-08-11 14:44:26 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
|
|
|
|
|
2021-09-27 14:59:58 -07:00
|
|
|
|
2022-06-19 08:05:52 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2021-08-25 18:31:03 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2021-08-25 18:31:03 +02:00
|
|
|
|
2021-06-02 09:53:34 +03:00
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:26 +02:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:07 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2021-08-25 18:31:04 +02:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2021-08-25 18:31:04 +02:00
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:04 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2021-08-25 18:31:04 +02:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-18 09:32:43 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2018-07-18 09:32:43 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-18 09:32:43 -07:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
2021-09-20 16:25:33 -07:00
|
|
|
|
2020-11-16 15:57:00 +01:00
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:04 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:48 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2022-05-21 15:37:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2022-05-21 15:37:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-23 18:13:01 -08:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2023-02-23 18:13:01 -08:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:07 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2021-08-25 18:31:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-14 18:25:33 +00:00
|
|
|
|
2022-07-23 16:24:27 +08:00
|
|
|
|
2021-08-25 18:31:08 +02:00
|
|
|
|
|
|
|
|
|
2017-08-14 18:25:33 +00:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2021-08-25 18:31:08 +02:00
|
|
|
|
2026-08-05 20:29:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-11 14:44:28 +02:00
|
|
|
|
2022-07-23 16:24:27 +08:00
|
|
|
|
2021-08-11 14:44:27 +02:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2023-11-17 00:23:14 +08:00
|
|
|
|
|
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-22 15:09:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:06 +05:30
|
|
|
|
2021-02-22 15:09:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-12 21:24:05 +08:00
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-12 21:24:05 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-10 20:49:20 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 23:13:30 +08:00
|
|
|
|
2022-03-22 16:06:39 +08:00
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
2021-08-13 23:13:30 +08:00
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
nbd: Fix hungtask when nbd_config_put
I got follow issue:
[ 247.381177] INFO: task kworker/u10:0:47 blocked for more than 120 seconds.
[ 247.382644] Not tainted 4.19.90-dirty #140
[ 247.383502] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 247.385027] Call Trace:
[ 247.388384] schedule+0xb8/0x3c0
[ 247.388966] schedule_timeout+0x2b4/0x380
[ 247.392815] wait_for_completion+0x367/0x510
[ 247.397713] flush_workqueue+0x32b/0x1340
[ 247.402700] drain_workqueue+0xda/0x3c0
[ 247.403442] destroy_workqueue+0x7b/0x690
[ 247.405014] nbd_config_put.cold+0x2f9/0x5b6
[ 247.405823] recv_work+0x1fd/0x2b0
[ 247.406485] process_one_work+0x70b/0x1610
[ 247.407262] worker_thread+0x5a9/0x1060
[ 247.408699] kthread+0x35e/0x430
[ 247.410918] ret_from_fork+0x1f/0x30
We can reproduce issue as follows:
1. Inject memory fault in nbd_start_device
-1244,10 +1248,18 @@ static int nbd_start_device(struct nbd_device *nbd)
nbd_dev_dbg_init(nbd);
for (i = 0; i < num_connections; i++) {
struct recv_thread_args *args;
-
- args = kzalloc(sizeof(*args), GFP_KERNEL);
+
+ if (i == 1) {
+ args = NULL;
+ printk("%s: inject malloc error\n", __func__);
+ }
+ else
+ args = kzalloc(sizeof(*args), GFP_KERNEL);
2. Inject delay in recv_work
-757,6 +760,8 @@ static void recv_work(struct work_struct *work)
blk_mq_complete_request(blk_mq_rq_from_pdu(cmd));
}
+ printk("%s: comm=%s pid=%d\n", __func__, current->comm, current->pid);
+ mdelay(5 * 1000);
nbd_config_put(nbd);
atomic_dec(&config->recv_threads);
wake_up(&config->recv_wq);
3. Create nbd server
nbd-server 8000 /tmp/disk
4. Create nbd client
nbd-client localhost 8000 /dev/nbd1
Then will trigger above issue.
Reason is when add delay in recv_work, lead to release the last reference
of 'nbd->config_refs'. nbd_config_put will call flush_workqueue to make
all work finish. Obviously, it will lead to deadloop.
To solve this issue, according to Josef's suggestion move 'recv_work'
init from start device to nbd_dev_add, then destroy 'recv_work'when
nbd device teardown.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211102015237.2309763-5-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-02 09:52:37 +08:00
|
|
|
|
2021-08-13 23:13:30 +08:00
|
|
|
|
|
|
|
|
|
2025-01-03 17:28:59 +08:00
|
|
|
|
2021-08-13 23:13:30 +08:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-23 18:13:01 -08:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 19:43:31 +08:00
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2021-05-12 19:43:31 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-23 18:13:01 -08:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
nbd: provide a way for userspace processes to identify device backends
Problem:
On reconfigure of device, there is no way to defend if the backend
storage is matching with the initial backend storage.
Say, if an initial connect request for backend "pool1/image1" got
mapped to /dev/nbd0 and the userspace process is terminated. A next
reconfigure request within NBD_ATTR_DEAD_CONN_TIMEOUT is allowed to
use /dev/nbd0 for a different backend "pool1/image2"
For example, an operation like below could be dangerous:
$ sudo rbd-nbd map --try-netlink rbd-pool/ext4-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="bfc444b4-64b1-418f-8b36-6e0d170cfc04" TYPE="ext4"
$ sudo pkill -9 rbd-nbd
$ sudo rbd-nbd attach --try-netlink --device /dev/nbd0 rbd-pool/xfs-image
/dev/nbd0
$ sudo blkid /dev/nbd0
/dev/nbd0: UUID="d29bf343-6570-4069-a9ea-2fa156ced908" TYPE="xfs"
Solution:
Provide a way for userspace processes to keep some metadata to identify
between the device and the backend, so that when a reconfigure request is
made, we can compare and avoid such dangerous operations.
With this solution, as part of the initial connect request, backend
path can be stored in the sysfs per device config, so that on a reconfigure
request it's easy to check if the backend path matches with the initial
connect backend path.
Please note, ioctl interface to nbd will not have these changes, as there
won't be any reconfigure.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210429102828.31248-1-prasanna.kalever@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-29 15:58:28 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
2023-11-17 00:23:15 +08:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2021-10-20 15:39:59 +08:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-29 15:16:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-13 11:39:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-22 15:09:53 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
2021-02-22 15:09:53 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
2019-09-17 17:26:05 +05:30
|
|
|
|
2018-06-15 14:05:32 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
2026-08-05 20:29:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-04-06 17:02:07 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2017-04-06 17:02:01 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
|
|
|
|
|
2022-08-24 17:18:30 -07:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2023-02-23 18:13:00 -08:00
|
|
|
|
genetlink: make policy common to family
Since maxattr is common, the policy can't really differ sanely,
so make it common as well.
The only user that did in fact manage to make a non-common policy
is taskstats, which has to be really careful about it (since it's
still using a common maxattr!). This is no longer supported, but
we can fake it using pre_doit.
This reduces the size of e.g. nl80211.o (which has lots of commands):
text data bss dec hex filename
398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
--------------------------------
-832 +8 0 -824
Which is obviously just 8 bytes for each command, and an added 8
bytes for the new policy pointer. I'm not sure why the ops list is
counted as .text though.
Most of the code transformations were done using the following spatch:
@ops@
identifier OPS;
expression POLICY;
@@
struct genl_ops OPS[] = {
...,
{
- .policy = POLICY,
},
...
};
@@
identifier ops.OPS;
expression ops.POLICY;
identifier fam;
expression M;
@@
struct genl_family fam = {
.ops = OPS,
.maxattr = M,
+ .policy = POLICY,
...
};
This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
the cb->data as ops, which we want to change in a later genl patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-21 22:51:02 +01:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2023-07-13 21:29:35 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 11:13:06 +02:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 11:13:06 +02:00
|
|
|
|
2024-02-17 20:25:38 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-19 13:14:07 +08:00
|
|
|
|
2017-04-06 17:02:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-06 17:02:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-25 03:07:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
NBD: add partition support
Permit the use of partitions with network block devices (NBD).
A new parameter is introduced to define how many partition we want to be able
to manage per network block device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
[on the server side]
# nbd-server 1234 /dev/sdb
[on the client side]
# modprobe nbd max_part=63
# ls -l /dev/nbd*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:14 /dev/nbd0
brw-rw---- 1 root disk 43, 64 2008-03-25 11:11 /dev/nbd1
brw-rw---- 1 root disk 43, 640 2008-03-25 11:11 /dev/nbd10
brw-rw---- 1 root disk 43, 704 2008-03-25 11:11 /dev/nbd11
brw-rw---- 1 root disk 43, 768 2008-03-25 11:11 /dev/nbd12
brw-rw---- 1 root disk 43, 832 2008-03-25 11:11 /dev/nbd13
brw-rw---- 1 root disk 43, 896 2008-03-25 11:11 /dev/nbd14
brw-rw---- 1 root disk 43, 960 2008-03-25 11:11 /dev/nbd15
brw-rw---- 1 root disk 43, 128 2008-03-25 11:11 /dev/nbd2
brw-rw---- 1 root disk 43, 192 2008-03-25 11:11 /dev/nbd3
brw-rw---- 1 root disk 43, 256 2008-03-25 11:11 /dev/nbd4
brw-rw---- 1 root disk 43, 320 2008-03-25 11:11 /dev/nbd5
brw-rw---- 1 root disk 43, 384 2008-03-25 11:11 /dev/nbd6
brw-rw---- 1 root disk 43, 448 2008-03-25 11:11 /dev/nbd7
brw-rw---- 1 root disk 43, 512 2008-03-25 11:11 /dev/nbd8
brw-rw---- 1 root disk 43, 576 2008-03-25 11:11 /dev/nbd9
# nbd-client localhost 1234 /dev/nbd0
Negotiation: ..size = 80418240KB
bs=1024, sz=80418240
-------NOTE, RFC: partition table is not automatically read.
The driver sets bdev->bd_invalidated to 1 to force the read of the partition
table of the device, but this is done only on an open of the device.
So we have to do a "touch /dev/nbdX" or something like that.
It can't be done from the nbd-client or nbd driver because at this
level we can't ask to read the partition table and to serve the request
at the same time (-> deadlock)
If someone has a better idea, I'm open to any suggestion.
-------NOTE, RFC
# fdisk -l /dev/nbd0
Disk /dev/nbd0: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/nbd0p1 * 1 9965 80043831 83 Linux
/dev/nbd0p2 9966 10011 369495 5 Extended
/dev/nbd0p5 9966 10011 369463+ 82 Linux swap / Solaris
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
brw-rw---- 1 root disk 43, 1 2008-03-25 11:16 /dev/nbd0p1
brw-rw---- 1 root disk 43, 2 2008-03-25 11:16 /dev/nbd0p2
brw-rw---- 1 root disk 43, 5 2008-03-25 11:16 /dev/nbd0p5
# mount /dev/nbd0p1 /mnt
# ls /mnt
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
cdrom home lib mnt root srv usr
# umount /mnt
# nbd-client -d /dev/nbd0
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
-------NOTE
On "nbd-client -d", we can do an iocl(BLKRRPART) to update partition table:
as the size of the device is 0, we don't have to serve the partition manager
request (-> no deadlock).
-------NOTE
Signed-off-by: Paul Clements <paul.clements@steeleye.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 01:02:51 -07:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
NBD: add partition support
Permit the use of partitions with network block devices (NBD).
A new parameter is introduced to define how many partition we want to be able
to manage per network block device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
[on the server side]
# nbd-server 1234 /dev/sdb
[on the client side]
# modprobe nbd max_part=63
# ls -l /dev/nbd*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:14 /dev/nbd0
brw-rw---- 1 root disk 43, 64 2008-03-25 11:11 /dev/nbd1
brw-rw---- 1 root disk 43, 640 2008-03-25 11:11 /dev/nbd10
brw-rw---- 1 root disk 43, 704 2008-03-25 11:11 /dev/nbd11
brw-rw---- 1 root disk 43, 768 2008-03-25 11:11 /dev/nbd12
brw-rw---- 1 root disk 43, 832 2008-03-25 11:11 /dev/nbd13
brw-rw---- 1 root disk 43, 896 2008-03-25 11:11 /dev/nbd14
brw-rw---- 1 root disk 43, 960 2008-03-25 11:11 /dev/nbd15
brw-rw---- 1 root disk 43, 128 2008-03-25 11:11 /dev/nbd2
brw-rw---- 1 root disk 43, 192 2008-03-25 11:11 /dev/nbd3
brw-rw---- 1 root disk 43, 256 2008-03-25 11:11 /dev/nbd4
brw-rw---- 1 root disk 43, 320 2008-03-25 11:11 /dev/nbd5
brw-rw---- 1 root disk 43, 384 2008-03-25 11:11 /dev/nbd6
brw-rw---- 1 root disk 43, 448 2008-03-25 11:11 /dev/nbd7
brw-rw---- 1 root disk 43, 512 2008-03-25 11:11 /dev/nbd8
brw-rw---- 1 root disk 43, 576 2008-03-25 11:11 /dev/nbd9
# nbd-client localhost 1234 /dev/nbd0
Negotiation: ..size = 80418240KB
bs=1024, sz=80418240
-------NOTE, RFC: partition table is not automatically read.
The driver sets bdev->bd_invalidated to 1 to force the read of the partition
table of the device, but this is done only on an open of the device.
So we have to do a "touch /dev/nbdX" or something like that.
It can't be done from the nbd-client or nbd driver because at this
level we can't ask to read the partition table and to serve the request
at the same time (-> deadlock)
If someone has a better idea, I'm open to any suggestion.
-------NOTE, RFC
# fdisk -l /dev/nbd0
Disk /dev/nbd0: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/nbd0p1 * 1 9965 80043831 83 Linux
/dev/nbd0p2 9966 10011 369495 5 Extended
/dev/nbd0p5 9966 10011 369463+ 82 Linux swap / Solaris
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
brw-rw---- 1 root disk 43, 1 2008-03-25 11:16 /dev/nbd0p1
brw-rw---- 1 root disk 43, 2 2008-03-25 11:16 /dev/nbd0p2
brw-rw---- 1 root disk 43, 5 2008-03-25 11:16 /dev/nbd0p5
# mount /dev/nbd0p1 /mnt
# ls /mnt
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
cdrom home lib mnt root srv usr
# umount /mnt
# nbd-client -d /dev/nbd0
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
-------NOTE
On "nbd-client -d", we can do an iocl(BLKRRPART) to update partition table:
as the size of the device is 0, we don't have to serve the partition manager
request (-> no deadlock).
-------NOTE
Signed-off-by: Paul Clements <paul.clements@steeleye.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 01:02:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-28 14:44:46 +02:00
|
|
|
|
NBD: add partition support
Permit the use of partitions with network block devices (NBD).
A new parameter is introduced to define how many partition we want to be able
to manage per network block device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
[on the server side]
# nbd-server 1234 /dev/sdb
[on the client side]
# modprobe nbd max_part=63
# ls -l /dev/nbd*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:14 /dev/nbd0
brw-rw---- 1 root disk 43, 64 2008-03-25 11:11 /dev/nbd1
brw-rw---- 1 root disk 43, 640 2008-03-25 11:11 /dev/nbd10
brw-rw---- 1 root disk 43, 704 2008-03-25 11:11 /dev/nbd11
brw-rw---- 1 root disk 43, 768 2008-03-25 11:11 /dev/nbd12
brw-rw---- 1 root disk 43, 832 2008-03-25 11:11 /dev/nbd13
brw-rw---- 1 root disk 43, 896 2008-03-25 11:11 /dev/nbd14
brw-rw---- 1 root disk 43, 960 2008-03-25 11:11 /dev/nbd15
brw-rw---- 1 root disk 43, 128 2008-03-25 11:11 /dev/nbd2
brw-rw---- 1 root disk 43, 192 2008-03-25 11:11 /dev/nbd3
brw-rw---- 1 root disk 43, 256 2008-03-25 11:11 /dev/nbd4
brw-rw---- 1 root disk 43, 320 2008-03-25 11:11 /dev/nbd5
brw-rw---- 1 root disk 43, 384 2008-03-25 11:11 /dev/nbd6
brw-rw---- 1 root disk 43, 448 2008-03-25 11:11 /dev/nbd7
brw-rw---- 1 root disk 43, 512 2008-03-25 11:11 /dev/nbd8
brw-rw---- 1 root disk 43, 576 2008-03-25 11:11 /dev/nbd9
# nbd-client localhost 1234 /dev/nbd0
Negotiation: ..size = 80418240KB
bs=1024, sz=80418240
-------NOTE, RFC: partition table is not automatically read.
The driver sets bdev->bd_invalidated to 1 to force the read of the partition
table of the device, but this is done only on an open of the device.
So we have to do a "touch /dev/nbdX" or something like that.
It can't be done from the nbd-client or nbd driver because at this
level we can't ask to read the partition table and to serve the request
at the same time (-> deadlock)
If someone has a better idea, I'm open to any suggestion.
-------NOTE, RFC
# fdisk -l /dev/nbd0
Disk /dev/nbd0: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/nbd0p1 * 1 9965 80043831 83 Linux
/dev/nbd0p2 9966 10011 369495 5 Extended
/dev/nbd0p5 9966 10011 369463+ 82 Linux swap / Solaris
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
brw-rw---- 1 root disk 43, 1 2008-03-25 11:16 /dev/nbd0p1
brw-rw---- 1 root disk 43, 2 2008-03-25 11:16 /dev/nbd0p2
brw-rw---- 1 root disk 43, 5 2008-03-25 11:16 /dev/nbd0p5
# mount /dev/nbd0p1 /mnt
# ls /mnt
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
cdrom home lib mnt root srv usr
# umount /mnt
# nbd-client -d /dev/nbd0
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
-------NOTE
On "nbd-client -d", we can do an iocl(BLKRRPART) to update partition table:
as the size of the device is 0, we don't have to serve the partition manager
request (-> no deadlock).
-------NOTE
Signed-off-by: Paul Clements <paul.clements@steeleye.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 01:02:51 -07:00
|
|
|
|
|
|
|
|
|
2011-05-28 14:44:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-28 14:44:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-04 14:10:06 -05:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
2017-04-06 17:02:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
2026-08-05 20:29:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2026-08-05 20:29:30 +08:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-17 08:20:06 +02:00
|
|
|
|
|
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-28 09:49:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2022-05-21 15:37:45 +08:00
|
|
|
|
2017-04-28 09:49:19 -04:00
|
|
|
|
2022-05-21 15:37:49 +08:00
|
|
|
|
2017-04-06 17:02:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-11 14:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-01 16:11:40 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-05-01 08:59:07 -07:00
|
|
|
|
NBD: add partition support
Permit the use of partitions with network block devices (NBD).
A new parameter is introduced to define how many partition we want to be able
to manage per network block device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
[on the server side]
# nbd-server 1234 /dev/sdb
[on the client side]
# modprobe nbd max_part=63
# ls -l /dev/nbd*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:14 /dev/nbd0
brw-rw---- 1 root disk 43, 64 2008-03-25 11:11 /dev/nbd1
brw-rw---- 1 root disk 43, 640 2008-03-25 11:11 /dev/nbd10
brw-rw---- 1 root disk 43, 704 2008-03-25 11:11 /dev/nbd11
brw-rw---- 1 root disk 43, 768 2008-03-25 11:11 /dev/nbd12
brw-rw---- 1 root disk 43, 832 2008-03-25 11:11 /dev/nbd13
brw-rw---- 1 root disk 43, 896 2008-03-25 11:11 /dev/nbd14
brw-rw---- 1 root disk 43, 960 2008-03-25 11:11 /dev/nbd15
brw-rw---- 1 root disk 43, 128 2008-03-25 11:11 /dev/nbd2
brw-rw---- 1 root disk 43, 192 2008-03-25 11:11 /dev/nbd3
brw-rw---- 1 root disk 43, 256 2008-03-25 11:11 /dev/nbd4
brw-rw---- 1 root disk 43, 320 2008-03-25 11:11 /dev/nbd5
brw-rw---- 1 root disk 43, 384 2008-03-25 11:11 /dev/nbd6
brw-rw---- 1 root disk 43, 448 2008-03-25 11:11 /dev/nbd7
brw-rw---- 1 root disk 43, 512 2008-03-25 11:11 /dev/nbd8
brw-rw---- 1 root disk 43, 576 2008-03-25 11:11 /dev/nbd9
# nbd-client localhost 1234 /dev/nbd0
Negotiation: ..size = 80418240KB
bs=1024, sz=80418240
-------NOTE, RFC: partition table is not automatically read.
The driver sets bdev->bd_invalidated to 1 to force the read of the partition
table of the device, but this is done only on an open of the device.
So we have to do a "touch /dev/nbdX" or something like that.
It can't be done from the nbd-client or nbd driver because at this
level we can't ask to read the partition table and to serve the request
at the same time (-> deadlock)
If someone has a better idea, I'm open to any suggestion.
-------NOTE, RFC
# fdisk -l /dev/nbd0
Disk /dev/nbd0: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/nbd0p1 * 1 9965 80043831 83 Linux
/dev/nbd0p2 9966 10011 369495 5 Extended
/dev/nbd0p5 9966 10011 369463+ 82 Linux swap / Solaris
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
brw-rw---- 1 root disk 43, 1 2008-03-25 11:16 /dev/nbd0p1
brw-rw---- 1 root disk 43, 2 2008-03-25 11:16 /dev/nbd0p2
brw-rw---- 1 root disk 43, 5 2008-03-25 11:16 /dev/nbd0p5
# mount /dev/nbd0p1 /mnt
# ls /mnt
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
cdrom home lib mnt root srv usr
# umount /mnt
# nbd-client -d /dev/nbd0
# ls -l /dev/nbd0*
brw-rw---- 1 root disk 43, 0 2008-03-25 11:16 /dev/nbd0
-------NOTE
On "nbd-client -d", we can do an iocl(BLKRRPART) to update partition table:
as the size of the device is 0, we don't have to serve the partition manager
request (-> no deadlock).
-------NOTE
Signed-off-by: Paul Clements <paul.clements@steeleye.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 01:02:51 -07:00
|
|
|
|
|
|
|
|
|
2017-08-14 18:56:16 +00:00
|
|
|
|
2026-08-05 20:29:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|