Hi Miklos, I got a couple of bug reports[1][2] this morning from teams that are tracking regresssions in linux-next. My patch 513dfacefd71 ("fuse: share lookup state between submount and its parent") is causing panics in the fuse unmount path. The reports came from users with SLUB_DEBUG enabled, and the additional debug sanitization catches the fact that the submount_lookup field isn't getting initialized which could lead to a subsequently bogus attempt to access the submount_lookup structure and adjust its refcount.
I've added SLUB_DEBUG to my testing kconfig, and have reproduced the problem using the memfd self-test that was triggering the problem for both reporters. With the fix that follows this e-mail, I see no more erroneous accesses of poisoned slub memory.
I'm a bit unsure of the desired approach for fixing these kinds of problems. I'm also away from the office on Nov 10th and Nov 13th, but expect to be back on the console on the Nov 14th. Given the gap, I've prepared a pair of patches, but we only need one.
The first is simply a followup fix that addresses the problem in a subsequent one-line commit.
If you'd rather revert the entire bad patch and go again, the second patch in the series is a v5 of the original with the submount_lookup initialization added.
Either should do, but I wasn't sure which approach was preferable.
Thanks, and my apologies for the inconvenience.
-K
[1] https://lore.kernel.org/linux-fsdevel/CA+G9fYue-dV7t-NrOhWwGshvyboXjb2B6HpCD... [2] https://lore.kernel.org/intel-gfx/SJ1PR11MB6129508509896AD7D0E03114B9AFA@SJ1...