Re: Serious error in autofs docs, which has design implications
Ian Kent <[email protected]> Fri, 22 Aug 2025 20:31:46 +0800
| Newsgroups | gmane.linux.file-systems,gmane.linux.kernel.autofs |
|---|---|
| Message-ID | <[email protected]> |
On 21/8/25 15:53, Askar Safin wrote: > Hi, Ian Kent and other autofs people. > > autofs.rst says: >> mounting onto a directory is considered to be "beyond a `stat`" > in https://elixir.bootlin.com/linux/v6.17-rc2/source/Documentation/filesystems/autofs.rst#L109 > > This is not true. Mounting does not trigger automounts. I don't understand that statement either, it's been many years since this was done and I can't remember the exact details. I didn't write this Neil Brown did and I have spoken with Neil many times over the years and although I'm quite sure we talked about this document at the time it was so long I don't actually remember what was said. It's quite likely that what I said at the time was misunderstood but the discussion following this is reasonably clear and describes the uses of the callback. The need to not race with an ongoing expire of an automounted mount is important and the transit through a non-empty directory in the case the automount map in use specifies a tree of mounts is important too (no this is not kernel only automounting such as is used by the likes of NFS it's functionality implemented by automount(8) based the mount map constructs it uses). So much of this is needed by the autofs file system during path traversal which is used by automount (not general file systems). > > mount syscall ( > https://elixir.bootlin.com/linux/v6.17-rc2/source/fs/namespace.c#L4321 > ) calls "do_mount" ( > https://elixir.bootlin.com/linux/v6.17-rc2/source/fs/namespace.c#L4124 > ), which calls "user_path_at" without LOOKUP_AUTOMOUNT. > This means automounts are not followed. > I didn't test this, but I'm pretty sure about this by reading code. Explain what you mean please. > > But what is worse, autofs.rst then proceeds to use this as an argument in > favor of introducing DCACHE_MANAGE_TRANSIT! I don't think that's the way you should be looking at this. At the time this was implemented into the VFS there were several things that autofs needed to do for automount(8) and David Howells chose to do it this way at the time after discussing what was needed with me. > > I. e. it seems that introducing DCACHE_MANAGE_TRANSIT rests on > wrong premise. I don't think so myself. But it may be possible to do it differently if there are reasons to do so. IIRC Al doesn't much like this either but even so I would need a clear description and discussion of how the cases I need are covered before changing this to some other method. > > Thus, it seems (from reading autofs.rst) that DCACHE_MANAGE_TRANSIT and all accociated logic > can be removed from kernel. Again I don't think that's the case at all, certainly automount(8) will see various breakage without changes to it and probably the autofs file system. IIRC (and I likely don't) I would probably need to re-introduce ->d_revalidate() to autofs and make sure that the VFS locking is consistent (which it wasn't at the when this was originally done and what was needed didn't seem to fit sensibly into ->d_revalidate() either) wrt. autofs's needs. So why do you need to change this? Ian