Messages in this thread | | | Date | Wed, 18 May 2022 04:38:53 +0000 | From | Al Viro <> | Subject | Re: [syzbot] WARNING in mntput_no_expire (3) |
| |
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.
| |