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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 04 Dec 2016 10:07:48 +0800
From:   Ian Kent <raven@...maw.net>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        autofs mailing list <autofs@...r.kernel.org>,
        Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Omar Sandoval <osandov@...ndov.com>
Subject: Re: [PATCH 1/7] vfs - merge path_is_mountpoint() and
 path_is_mountpoint_rcu()

On Sat, 2016-12-03 at 05:13 +0000, Al Viro wrote:
> 	FWIW, I've folded that pile into vfs.git#work.autofs.
> 
> Problems:
> 	* (fixed) __path_is_mountpoint() should _not_ treat NULL from
> __lookup_mnt() as "nothing's mounted there" until it has checked
> that mount_lock hadn't been touched - mount --move on something unrelated
> can race with lockless hash lookup and lead to false negatives.

Right, looking at what you've done there the mistake is so obvious now!
Thanks for helping with it.

> 	* linux/mount.h might be the wrong place for path_is_mountpoint().
> Or it shouldn't be inlined.  I don't like the includes you've added there.
> 	* path_has_submounts() is broken.  At the very least, it's
> AB-BA between mount_lock and rename_lock.  I would suggest trying to
> put read_seqlock_excl(&mount_lock) around the call of d_walk() in there,
> and using __lookup_mnt() in the callback (without retries on the mount_lock,
> of course - read_seqlock_excl done on the outside is enough).  I'm not sure
> if it won't cause trouble with contention, though; that needs testing.  As
> it is, that function is broken in #work.autofs, same as it is in -mm and
> -next.

Umm ... that's a much more obvious dumb mistake and what you've done there
didn't occur to me even after you spelled it out, I'll take some time to digest
it. And thanks for that one too.

Ian

Powered by blists - more mailing lists