linux-kernel - Re: [rfc][possible solution] RCU vfsmounts

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]

Message-ID: <CA+55aFyGY7hZTDhWiyWBe+oSkxd2GzoYWGhvXtGTyZKL-3PZ1w@mail.gmail.com>
Date:	Sun, 29 Sep 2013 10:19:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc][possible solution] RCU vfsmounts

On Sat, Sep 28, 2013 at 11:06 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Sigh...  Looks like there's a lot of fun in shrink_dcache_for_umount() -
> at the very least, it needs to bump ->d_seq on everything, because with
> that change we *can* walk into a filesystem in the middle of that.
> We obviously don't want to slap rcu_barrier() into the final mntput() -

I have to say, that when I was working with the dcache lockref code, I
absolutely _detested_ the magical shrink_dcache_for_umount() code that
violated all the locking rules.

So I actually wouldn't mind at all if that was all forced to follow
all the same rules that the live filesystem code is forced to follow.
Yes, yes, it's going to slow things down, but it's not like umount()
is _that_ performance critical. And I think the whole "let's ignore
locking rules" actually comes from back when we had one global
dcache_lock: we used to have batching in order to not hold the
dcache_lock over long periods, and then it got converted to the
per-dentry locking, and then that got removed entirely with the whole
RCU lookup etc.

So I would be *entirely* ok with having
shrink_dcache_for_umount_subtree() take the d_lock on the dentry as it
shrinks it etc etc.

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/