On Tue, Jun 06, 2023 at 11:24:32AM +1000, Dave Chinner wrote: > On Mon, Jun 05, 2023 at 05:38:27PM -0700, Roman Gushchin wrote: > > Hm, it makes the API more complex and easier to mess with. Like what will happen > > if the second part is never called? Or it's called without the first part being > > called first? > > Bad things. > > Also, it doesn't fix the three other unregister_shrinker() calls in > the XFS unmount path, nor the three in the ext4/mbcache/jbd2 unmount > path. > > Those are just some of the unregister_shrinker() calls that have > dynamic contexts that would also need this same fix; I haven't > audited the 3 dozen other unregister_shrinker() calls around the > kernel to determine if any of them need similar treatment, too. > > IOWs, this patchset is purely a band-aid to fix the reported > regression, not an actual fix for the underlying problems caused by > moving the shrinker infrastructure to SRCU protection. This is why > I really want the SRCU changeover reverted. There's been so much traffic on linux-fsdevel so I missed this thread until Darrick pointed it out to me today. (Thanks, Darrick!) >From his description, and my quick read-through of this thread.... I'm worried. Given that we're at -rc5 now, and the file system folks didn't get consulted until fairly late in the progress, and the fact that this may cause use-after-free problems that could lead to security issues, perhaps we shoould consider reverting the SRCU changeover now, and try again for the next merge window? Thanks!! - Ted