[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230914-jeweiligen-normung-47816c153531@brauner>
Date: Thu, 14 Sep 2023 11:36:35 +0200
From: Christian Brauner <brauner@...nel.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Miklos Szeredi <mszeredi@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
linux-security-module@...r.kernel.org, Karel Zak <kzak@...hat.com>,
Ian Kent <raven@...maw.net>,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Amir Goldstein <amir73il@...il.com>
Subject: Re: [RFC PATCH 1/3] add unique mount ID
> Yes, one concern is that humans confuse the old and the new ID.
>
> I also think it makes sense to allow the new interfaces to look up the
> mount based on either the old or the new ID. But I could be wrong
Hm, mount id recycling may happen so quickly that for service restarts
with a lot of mounts this becomes mostly useless...
> there, since that might encourage bad code. Maybe the new interface
> should only use take the new ID, which means no mixed use of
> /proc/$$/mountinfo and statmnt/listmnt.
... so I think that is indeed the better way of doing things. There's no
need to encourage userspace to mix both identifiers.
Powered by blists - more mailing lists