From: Brian Geffon <bgeffon@google.com>
To: Brian Geffon <bgeffon@google.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dm: introduce a no open flag for deferred remove
Date: Mon, 24 Jan 2022 10:25:47 -0500 [thread overview]
Message-ID: <CADyq12ykDCswWZw05OdyYfP-zT6afuhXbckii1m1egQ2fSwB4w@mail.gmail.com> (raw)
In-Reply-To: <20220124151434.GB20331@agk-cloud1.hosts.prod.upshift.rdu2.redhat.com>
On Mon, Jan 24, 2022 at 10:14 AM Alasdair G Kergon <agk@redhat.com> 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
next prev parent reply other threads:[~2022-01-24 15:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 15:02 [PATCH] dm: introduce a no open flag for deferred remove Brian Geffon
2022-01-24 15:14 ` Alasdair G Kergon
2022-01-24 15:25 ` Brian Geffon [this message]
2022-01-25 0:20 ` Alasdair G Kergon
2022-01-25 14:25 ` Brian Geffon
2022-01-25 17:11 ` Brian Geffon
2022-01-26 19:22 ` [PATCH] dm: introduce a DM_ENFORCE_OPEN_COUNT flag Brian Geffon
2022-01-31 14:17 ` Brian Geffon
2022-02-02 14:42 ` Christoph Hellwig
2022-02-22 19:16 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADyq12ykDCswWZw05OdyYfP-zT6afuhXbckii1m1egQ2fSwB4w@mail.gmail.com \
--to=bgeffon@google.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).