[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1480817915.3157.14.camel@themaw.net>
Date: Sun, 04 Dec 2016 10:18:35 +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 23:29 +0000, Al Viro wrote:
> On Sat, Dec 03, 2016 at 05:13:22AM +0000, Al Viro wrote:
> >
> > * 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.
> Fix for path_has_submounts() (as above) force-pushed. It does
> need testing and profiling, obviously.
I'll run my tests against it and re-run with oprofile if all goes well.
The submount-test I use should show contention if it's a problem but I'm not
sure the number of mounts used will be sufficient to show up scale problems.
Basically each case of the test (there are two) runs for 100 iterations using 10
processes with timing set to promote expire to mount contention, mainly to test
for expire to mount races.
If I don't see contention I might need to analyse further whether the test has
adequate coverage.
Ian
Powered by blists - more mailing lists