From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=themaw.net header.i=@themaw.net header.b="fwwlqwjJ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="oAHuVFE1" Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C379CA2; Mon, 20 Nov 2023 17:33:46 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A54CD5C14AE; Mon, 20 Nov 2023 20:33:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 20 Nov 2023 20:33:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700530423; x=1700616823; bh=R8SiaLMulONYSs7gpNiz/SIhkos3i9d3i6m xfRPyilU=; b=fwwlqwjJcZvWK43sMcTfBsEtIn7Oi6hyJAtEsIDiEReSAtHgWyv z8MAo+ey07qHQzjF5TPbU1PpN2UuKaGMMbI+zkSsQ3ebZIW3HtUETLIzQNUypuzX uN41JtTqupfYEtOF/Q88PRwh7Vp3qlu6dVsVdkjRTX4No/ctvEufBBOKZOypesz1 z8HSHyBuW9ny1MnA5gSFsVZWySTD0kJw+0DsuB0Ts9C/2JODj3CZUve/e6Y68fGU 19X+duwCtA3TiMvKSySMsT2hq7eIaTHTrSAD0DqD+sdJAvljZsXlJ800MeNb+8JG G/QMdygkn1rnrpD6qYQxJfeeaQna5QnIKyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700530423; x=1700616823; bh=R8SiaLMulONYSs7gpNiz/SIhkos3i9d3i6m xfRPyilU=; b=oAHuVFE16KCWNKxT43dcCLNPA90ggCPOQrp7pqviNBOshIRjUal 5gs9jL/ciUKqVBgQonnxAT6tQSK4dA02WNjcFaxUoNbeJhYkHbXGOtwpSIEmEVgg ncEV7kuNTTd4Zgr+Vya2E1DEA1vJpsu3CjPRN2UuJU1LaQLViK2TPayUNcHIjGAb or0G7PxlGqOZkIPFtWj0Ks5UkmA01jL4FI3Dnwvo4KTidkSroEk5i11YHT4O/6Pr mCby9g33nIxyeMPAfRVfty+VXo7n6ULJktHcslgXKHOOdOrbHlJeAp4cxOQKyUo1 Ttdb00G+QSXbpoy42U5D7Z6GZdo6L5KE71A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudegkedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfvfevfhfhufgjtgfgsehtkeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epueejtdffffeuheefgfdvfeekudffvdejveevudekveevkeehtdehgeekueejvdevnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 20 Nov 2023 20:33:38 -0500 (EST) Message-ID: Date: Tue, 21 Nov 2023 09:33:36 +0800 Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Ian Kent , Miklos Szeredi , Florian Weimer Cc: libc-alpha@sourceware.org, linux-man , Alejandro Colomar , Linux API , linux-fsdevel@vger.kernel.org, Karel Zak , David Howells , Christian Brauner , Amir Goldstein , Arnd Bergmann References: <87fs15qvu4.fsf@oldenburg.str.redhat.com> <87leawphcj.fsf@oldenburg.str.redhat.com> <878r6soc13.fsf@oldenburg.str.redhat.com> <15b01137-6ed4-0cd8-4f61-4ee870236639@redhat.com> <6aa721ad-6d62-d1e8-0e65-5ddde61ce281@themaw.net> From: Ian Kent Subject: Re: proposed libc interface and man page for statmount(2) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 21/11/23 09:12, Ian Kent wrote: > On 21/11/23 08:58, Ian Kent wrote: >> On 21/11/23 07:56, Ian Kent wrote: >>> On 20/11/23 20:34, Miklos Szeredi wrote: >>>> On Mon, Nov 20, 2023 at 01:16:24PM +0100, Florian Weimer wrote: >>>>> Is the ID something specific to the VFS layer itself, or does it come >>>>> from file systems? >>>> It comes from the VFS. >>>> >>>> >>>>> POSIX has a seekdir/telldir interface like that, I don't think file >>>>> system authors like it.  Some have added dedicated data structures >>>>> for >>>>> it to implement somewhat predictable behavior in the face of >>>>> concurrent >>>>> directory modification.  Would this interface suffer from similar >>>>> issues? >>>> The same issue was solved for /proc/$$/mountinfo using cursors. >>> >>> The mounts are now using an rb-tree, I think the the cursor solution >>> can >>> >>> only work for a linear list, the case is very different. >>> >>> >>>> >>>> This patchset removes the need for cursors, since the new unique >>>> mount ID can be >>>> used to locate the current position without having to worry about >>>> deleted and >>>> added mounts. >>> >>> IIRC the problem with proc mounts traversals was because the lock >>> was taken >>> >>> and dropped between reads so that mount entries could be deleted >>> (not sure >>> >>> adding had quite the same problem) from the list in between reads. >>> >>> >>> Sounds like I'll need to look at the code but first though but an >>> rb-tree >>> >>> can have mounts removed and new mounts inserted if the locks are >>> dropped >>> >>> if the retrieval is slit between multiple calls. >>> >>> >>> So I'm struggling to see why this isn't the same problem and I don't >>> think >>> >>> introducing cursors in this case would work (thankfully, lets do >>> this again >>> >>> please). >> >> Mmm ... apologies for the poor description above. >> >> That last bit is definitely "lets 'not' do this again please!" > > IMHO keeping it simpler is much better. > > > The interface where a buffer is passed and overflow returns an error > so that one > > can retry is far simpler and the in-kernel simplification of taking > the lock over > > the whole retrieval is far less problematic. > > > If there's anything that could be useful then it's keeping a count of > the mounts > > in a given namespace (I think we have such a count in nsproxy struct > already) and > > adding a way to get that for storage needs estimation. I've completely lost what we are talking about. I think it was the introduction of listmount() earlier so my comment does apply to that but it's getting just mount ids so the allocation isn't huge even for a large number of mounts so I don't think there's a need for complexity. Then statmount() is retrieving the info for a single mount id, that's quite specific info. and not that hard to estimate the needed allocation so the error return and retry does seem like the most sensible thing. The fact is that getting a list of mount ids and then working through them meant you would be working with an outdated mounts list almost all the time. That's nothing new for what this is used for and is sufficiently functional. There are times when you do need a specific mount, such as SIGCHLD processing, but then we are working with a specific mount id so it's not a problem. > > > Ian > >