Re: [syzbot] WARNING in mntput_no_expire (3)

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, May 18, 2022 at 01:58:40AM +0000, Al Viro wrote:
> On Wed, May 18, 2022 at 01:10:20AM +0000, Al Viro wrote:
> > On Wed, May 18, 2022 at 12:59:46AM +0000, Al Viro wrote:
> > > On Tue, May 17, 2022 at 10:58:15PM +0000, Al Viro wrote:
> > > > On Tue, May 17, 2022 at 03:49:07PM -0700, syzbot wrote:
> > > > > Hello,
> > > > > 
> > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > > > WARNING in mntput_no_expire
> > > > 
> > > > Obvious question: which filesystem it is?
> > > 
> > > FWIW, can't reproduce here - at least not with C reproducer +
> > > -rc7^ kernel + .config from report + debian kvm image (bullseye,
> > > with systemd shite replaced with sysvinit, which might be relevant).
> > > 
> > > In case systemd-specific braindamage is needed to reproduce it...
> > > Hell knows; at least mount --make-rshared / doesn't seem to suffice.
> > 
> > ... doesn't reproduce with genuine systemd either.  FWIW, 4-way SMP
> > setup here.
> 
> OK, reproduced...

FWIW, it smells like something (cgroup?) fucking up percpu allocation/freeing.
Note that struct mount has both refcount and writers count held in percpu;
replacing the refcount with atomic_t gets rid of seeing negative refcount
in mntput_no_expire(), but leaves negative writers count caught in
cleanup_mnt(); turn that from WARN_ON into printk and we get past that,
only to see
	percpu ref (css_release) <= 0 (-4294967294)
immediately afterwards.

IOW, it looks like we are getting not messed refcounting on either side,
but same refcount physically shared by unrelated objects.