From: Al Viro <viro@zeniv.linux.org.uk>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: Neil Brown <neilb@suse.de>, Jeffrey Layton <jlayton@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Dave Wysochanski <dwysocha@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-nfs <linux-nfs@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: allowing for a completely cached umount(2) pathwalk
Date: Fri, 14 Apr 2023 05:21:04 +0100 [thread overview]
Message-ID: <20230414042104.GI3390869@ZenIV> (raw)
In-Reply-To: <93A5B3C4-0E20-4531-9B65-0D24C092CE70@hammerspace.com>
On Fri, Apr 14, 2023 at 04:06:03AM +0000, Trond Myklebust wrote:
>
>
> > On Apr 13, 2023, at 23:51, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >
> > On Fri, Apr 14, 2023 at 03:28:45AM +0000, Trond Myklebust wrote:
> >
> >> We already have support for directory file descriptors when mounting with move_mount(). Why not add a umountat() with similar support for the unmount side?
> >> Then add a syscall to allow users with (e.g.) the CAP_DAC_OVERRIDE privilege to convert the mount-id into an O_PATH file descriptor.
> >
> > You can already do umount -l /proc/self/fd/69 if you have a descriptor.
> > Converting mount-id to O_PATH... might be an interesting idea.
>
> A dedicated umountat() might avoid the need for the lazy flag, if it were allowed to close the descriptor on success for the special case of an empty path.
No. It's a wrong abstraction layer, anyway - "close the descriptor"
!= "make the opened file close", nevermind that it's a very odd
corner case that will cause a lot of headache down the road.
next prev parent reply other threads:[~2023-04-14 4:21 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 22:00 allowing for a completely cached umount(2) pathwalk Jeff Layton
2023-04-13 22:25 ` Andreas Dilger
2023-04-13 22:41 ` NeilBrown
2023-04-14 2:43 ` Al Viro
2023-04-14 3:28 ` Trond Myklebust
2023-04-14 3:51 ` Al Viro
2023-04-14 4:06 ` Trond Myklebust
2023-04-14 4:21 ` Al Viro [this message]
2023-04-14 9:41 ` Christian Brauner
2023-04-14 10:09 ` Jeff Layton
2023-04-14 11:16 ` Christian Brauner
2023-04-14 12:33 ` Jeff Layton
2023-04-14 12:51 ` Christian Brauner
2023-04-15 9:51 ` Amir Goldstein
2023-04-14 10:06 ` Jeff Layton
2023-04-14 13:41 ` Christian Brauner
2023-04-14 14:21 ` Trond Myklebust
2023-04-14 15:13 ` Christian Brauner
2023-04-14 15:30 ` Trond Myklebust
2023-04-14 15:57 ` Trond Myklebust
2023-04-14 16:22 ` Al Viro
2023-04-14 16:41 ` Trond Myklebust
2023-04-14 19:01 ` Benjamin Coddington
2023-04-17 8:22 ` Christian Brauner
2023-04-14 16:32 ` Christian Brauner
2023-04-14 2:32 ` Al Viro
2023-04-14 10:01 ` Jeff Layton
2023-04-14 12:18 ` Christian Brauner
2023-04-14 14:57 ` Al Viro
2023-04-14 13:16 ` David Wysochanski
2023-04-16 23:13 ` [PATCH/RFC] VFS: LOOKUP_MOUNTPOINT should used cached info whenever possible NeilBrown
2023-04-17 1:08 ` kernel test robot
2023-04-17 3:51 ` kernel test robot
2023-04-17 11:55 ` Christian Brauner
2023-04-17 12:25 ` Jeff Layton
2023-04-17 14:24 ` Christian Brauner
2023-04-17 15:21 ` Jeff Layton
2023-04-17 21:34 ` NeilBrown
2023-04-18 8:10 ` Christian Brauner
2023-04-18 3:25 ` Andreas Dilger
2023-04-18 8:04 ` Christian Brauner
2023-04-20 13:05 ` Jeff Layton
2023-04-20 15:41 ` Christian Brauner
2023-04-17 21:26 ` NeilBrown
2023-04-20 21:35 ` Al Viro
2023-04-20 22:01 ` NeilBrown
2023-04-20 22:27 ` Al Viro
2023-04-17 12:09 ` Jeff Layton
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=20230414042104.GI3390869@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=dwysocha@redhat.com \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@hammerspace.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.