[PATCH review 0/7] Bind mount escape fixes

[Eric W. Biederman]

On August 21, 2015 12:51:05 AM PDT, Al Viro <viro at ZenIV.linux.org.uk> wrote:
>On Sun, Aug 16, 2015 at 06:33:21AM -0500, Eric W. Biederman wrote:
>
>> > ... or either of us can do merging those checks into a single
>place,
>> > be it as a followup to your 7-patch series, or folded with the
>> > fs/dcache.c-affecting patches in there.  If you have no time left,
>I can
>> > certainly do that followup myself - not a problem[1]
>> 
>> I don't have time.  Everytime I have worked with this it has take
>pretty
>> much full days of staring at the code, and I don't have any more full
>> days left before the merge window.
>
>OK, at that point I've pretty much given up on fs_pin for this cycle.
>And testing your variant with unconditional checks on .. appears to
>have
>fairly low overhead.  I still want to deal with catching and unmounting
>the
>unreachable suckers, so fs/dcache.c side of things will get used when
>we get
>to that stuff, but for now I've taken your 1/7, 2/7 plus the variant of
>"vfs: Test for and handle paths that are unreachable from their
>mnt_root"
>that doesn't care whether anything escaped or not.
>
>3--6 are held in a local branch for now; I *am* going to use them
>come next cycle.  And there's another pile of fun around that area,
>also
>for the next cycle - kernel-initiated subtree removals on things like
>sysfs et.al.; handling of the locking in those is inconsistent and tied
>with the fun we have for d_move()/__d_unalias().  Sigh...


I am sorry to hear about a mess in sysfs. 

I am glad to hear that we do not appear to need MNT_DIR_ESCAPED to avoid performance regressions.  That should make back porters lives much easier.


As for the future I have a suspicion that we want to look at the rcu readable dynamically sized hash tables the networking guys cooked up.

Al thank you very much for performance testing the simple version.

Eric