Re: proposed libc interface and man page for statmount(2)

Ian Kent
2023-11-21T00:58:56Z

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!"

Ian