On Mon, Jan 24, 2022 at 10:14 AM Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > > On Mon, Jan 24, 2022 at 07:02:09AM -0800, Brian Geffon wrote: > > When a device is being removed with deferred remove it's > > still possible to open and use the device. This change > > introduces a flag called DM_DEFERRED_REMOVE_NO_OPEN_FLAG > > which when used with DM_DEFERRED_REMOVE will cause any > > new opens to fail with -ENXIO. > > What is the need for this? Hi Alasdair, Thank you for looking at this. There are a few reasons this might be useful, the first is if you're trying to speed up a graceful teardown of the device by informing userspace that this device is going to be removed in the near future. Another might be on systems where it might be worthwhile to not have users with CAP_DAC_OVERRIDE be able to open the device. The logic on this second case is that, suppose you have a dm-crypt block device which is backing swap, the data on this device is ephemeral so a flow might be to setup swap followed by dmsetup remove --deferred /dev/mapper/encrypted-swap. This will guarantee that as soon as swap is torn down the encrypted block device is dropped, additionally with this new flag you'll be guaranteed that there can be no further opens on it. > Does it break any semantics assumed by userspace? No, this is fully backwards compatible with the current deferred remove behavior, it's not required. Additionally, since on the actual remove userspace would receive an -ENXIO already once the remove process has started it seems reasonable to return -ENXIO in the deferred remove case when this flag is enabled. Brian -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
