linux-kernel - Re: [PATCH 3/6] autofs4: allow RCU-walk to walk through autofs4.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Jul 2014 11:51:01 +1000
From:	NeilBrown <neilb@...e.de>
To:	Ian Kent <raven@...maw.net>
Cc:	autofs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] autofs4: allow RCU-walk to walk through autofs4.

On Thu, 17 Jul 2014 18:17:32 +0800 Ian Kent <raven@...maw.net> wrote:

> 
> On Thu, 2014-07-17 at 18:04 +1000, NeilBrown wrote:
> > If there some documentation about the interactions between the automountd and
> > the kernel?
> 
> Not really, only the ioctl interaction described in
> Documentation/filesystems/autofs4-mount-control.txt
> 
> > It looks like:
> >  With V5, every name in the root directory gets something mounted on it,
> >       either another autofs or the target filesystem.
> >  With V4, you don't mount an autofs onto an autofs, but when a name in the
> >       root is automounted, all the names beneath there are created and the
> >       target filesystems are mounted before the top level automount is
> >       acknowledged.
> > 
> > Does that sound at all right (I suspect I haven't explained it very clearly).
> 
> Mostly, but let me try and simplify it (or perhaps confuse you even more
> and bore you as a bonus, ;)) and offer a broader picture.

Thanks for going into all that detail!  Having read that, and read the code
(a few times) and having tried to document it myself I think I really
understand it all now.

I wanted to be sure I understood from the perspective of what the module
actually supports rather than just how the automount daemon uses it, so I put
together a document describing the module.  At 3000 words, I'm not sure
whether to call it "verbose" or "thorough".  I'll post it separately.

I did discover one thing that is important for the RCU-walk work.
If you have a "root-less multimount" then the top-level directory will have
DCACHE_NEED_AUTOMOUNT set even though it is not a mount-trap.
As it contains a sub-directory (or more), d_manage will return -EISDIR so
normal REF-walking will side-step d_automount and it will be treated as a
normal directory.
However in RCU-walk mode, d_manage cannot usefully return -EISDIR so the VFS
will always drop into REF-walk mode, which negates some of the value of my
RCU-walk patches.

I see two ways to fix this:
 1- clear DCACHE_NEED_AUTOMOUNT when creating a subdir or symlink, just like
    we do with protocol-version 4
 2- teach the VFS to accept -EISDIR from d_manage and to ignore
    DCACHE_NEED_AUTOMOUNT in that case.  I have a patch to do this and it is
    fairly straight forward.

I think I prefer 2 (it seems easier to document:-) but thought I'd ask if you
have an opinion before I post it (I haven't even tested it properly yet).

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)