On Mon, Nov 14, 2022 at 05:29:44AM +0100, Christoph Hellwig wrote:
> blk_crypto_get_keyslot, blk_crypto_put_keyslot, __blk_crypto_evict_key
> and __blk_crypto_cfg_supported are only used internally by the
> blk-crypto code, so move the out of blk-crypto-profile.h, which is
> included by drivers th
From: Yu Kuai
After creating a dm device, then user can reload such dm with itself,
and dead loop will be triggered because dm keep looking up to itself.
Test procedures:
1) dmsetup create test --table "xxx sda", assume dm-0 is created
2) dmsetup suspend test
3) dmsetup reload test --table "xxx
From: Christoph Hellwig
Move all the logic for allocation the table_device and linking it into
the list into the open_table_device. This keeps the code tidy and
ensures that the table_devices only exist in fully initialized state.
Signed-off-by: Christoph Hellwig
Signed-off-by: Yu Kuai
---
d
From: Yu Kuai
open_table_device() and close_table_device() is protected by
table_devices_lock, hence use it to protect add_disk() and
del_gendisk().
Prepare to track per-add_disk holder relations in dm.
Signed-off-by: Yu Kuai
---
drivers/md/dm.c | 16
1 file changed, 16 inser
From: Christoph Hellwig
Take the list unlink and free into close_table_device so that no half
torn down table_devices exist. Also remove the check for a NULL bdev
as that can't happen - open_table_device never adds a table_device to
the list that does not have a valid block_device.
Signed-off-b
From: Christoph Hellwig
dm is a bit special in that it opens the underlying devices. Commit
89f871af1b26 ("dm: delay registering the gendisk") tried to accommodate
that by allowing to add the holder to the list before add_gendisk and
then just add them to sysfs once add_disk is called. But that
From: Christoph Hellwig
Now that dm has been fixed to track of holder registrations before
add_disk, the somewhat buggy block layer code can be safely removed.
Signed-off-by: Christoph Hellwig
Signed-off-by: Yu Kuai
---
block/genhd.c | 4 ---
block/holder.c | 72
From: Christoph Hellwig
free_table_devices just warns and frees all table_device structures when
the target removal did not remove them. This should never happen, but
if it did, just freeing the structure without deleting them from the
list or cleaning up the resources would not help at all. So
From: Yu Kuai
Hi all,
this series tries to fix the delayed holder tracking that is only used by
dm by moving it into dm, where we can track the lifetimes much better.
v2 is from Christoph, here I send v3 with some additional fixes.
Changes since v2:
- add patch 5 8 and 10 to this series.
- re
From: Christoph Hellwig
Zero out the pointer to ->slave_dir so that the holder code doesn't
incorrectly treat the object as alive when add_disk failed or after
del_gendisk was called.
Fixes: 89f871af1b26 ("dm: delay registering the gendisk")
Reported-by: Yu Kuai
Signed-off-by: Christoph Hellwig
On Mon, Nov 14, 2022 at 06:31:36AM -0500, Mikulas Patocka wrote:
>
>
> On Fri, 11 Nov 2022, Keith Busch wrote:
>
> > > There are other DM targets that override logical_block_size in their
> > > .io_hints hook (writecache, ebs, zoned). Have you reasoned through why
> > > those do _not_ need updat
From: Yu Kuai
We hold a reference to the holder kobject for each bd_holder_disk,
so to make the code a bit more robust, use a reference to it instead
of the block_device. As long as no one clears ->bd_holder_dir in
before freeing the disk, this isn't strictly required, but it does
make the code
From: Yu Kuai
Currently, the caller of bd_link_disk_holer() get 'bdev' by
blkdev_get_by_dev(), which will look up 'bdev' by inode number 'dev'.
Howerver, it's possible that del_gendisk() can be called currently, and
'bd_holder_dir' can be freed before bd_link_disk_holer() access it, thus
use afte
On Wed, 2022-11-09 at 15:49 -0600, Benjamin Marzinski wrote:
> Here are some cleanups (in response to comments from Martin Wilck)
> for
> patches I previously posted.
>
> Benjamin Marzinski (3):
> libmultipath: impove add_feature() variable names
> multipathd: don't initialize the field width
This commit flushes the journal on suspend. It is prerequisite for the
next commit that enables to activate dm integrity devices in read-only
mode.
Note that we deliberately didn't flush the journal on suspend, so that the
journal replay code would be tested. However, the dm-integrity code is 5
There was a problem that the user burned dm-integrity image on CDROM and
could not activate it becaues it had non-empty journal.
We fix this problem by flusing the journal (it is done by the previous
patch) and clearing the journal (it is done by this patch). When we clear
the journal, dm-integr
Just calling wait_for_device_probe() is not enough to ensure that
asynchronously probed block devices are available (E.G. mmc, usb, ..), so
add a "dm-mod.waitfor=[,..,]" parameter to get dm-init to
explicitly wait for specific block devices before initializing the tables
with logic similar to the
On Mon, Nov 14, 2022 at 05:29:42AM +0100, Christoph Hellwig wrote:
> Switch all public blk-crypto interfaces to use struct block_device
> arguments to specify the device they operate on instead of th
> request_queue, which is a block layer implementation detail.
>
> Signed-off-by: Christoph Hellwi
On Mon, Nov 14, 2022 at 05:29:43AM +0100, Christoph Hellwig wrote:
> Add a blk_crypto_config_supported_natively helper that wraps
> __blk_crypto_cfg_supported to retrieve the crypto_profile from the
> request queue. With this fscrypt can stop including
> blk-crypto-profile.h and rely on the public
On Mon, Nov 14, 2022 at 05:29:44AM +0100, Christoph Hellwig wrote:
> blk_crypto_get_keyslot, blk_crypto_put_keyslot, __blk_crypto_evict_key
> and __blk_crypto_cfg_supported are only used internally by the
> blk-crypto code, so move the out of blk-crypto-profile.h, which is
> included by drivers th
Just calling wait_for_device_probe() is not enough to ensure that
asynchronously probed block devices are available (E.G. mmc, usb, ..), so
add a "dm-mod.waitfor=[,..,]" parameter to get dm-init to
explicitly wait for specific block devices before initializing the tables
with logic similar to the
Looks good:
Reviewed-by: Christoph Hellwig
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Looks good:
Reviewed-by: Christoph Hellwig
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Looks good:
Reviewed-by: Christoph Hellwig
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Looks good:
Reviewed-by: Christoph Hellwig
(I'd even place this first in the series)
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
25 matches
Mail list logo
