On Wed, May 17, 2023 at 10:07:55AM +0300, Amir Goldstein wrote: > On Wed, May 17, 2023 at 3:08 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > Hi folks, > > > > Hi Dave, > > > The following patches are fixes for recently discovered problems. > > I'd like to consider them all for a 6.4-rc merge, though really only > > patch 2 is a necessary recent regression fix. > > > > The first patch addresses a long standing buffer UAF during shutdown > > situations, where shutdown log item completions can race with CIL > > abort and iclog log item completions. > > > > Can you tell roughly how far back this UAF bug goes > or is it long standing enough to be treated as "forever"? Longer than I cared to trace the history back. > > The second patch addresses a small performance regression from the > > 6.3 allocator rewrite which is also a potential AGF-AGF deadlock > > vector as it allows out-of-order locking. > > > > The third patch is a change needed by patch 4, which I split out for > > clarity. By itself it does nothing. > > > > The fourth patch is a fix for a AGI->AGF->inode cluster buffer lock > > ordering deadlock. This was introduced when we started pinning inode > > cluster buffers in xfs_trans_log_inode() in 5.8 to fix long-standing > > inode reclaim blocking issues, but I've only seen it in the wild > > once on a system making heavy use of OVL and hence O_TMPFILE based > > operations. > > Thank you for providing Fixes and this summary with backporing hints :) I don't think you're going to be able to backport the inode cluster buffer lock fix. Nothing prior to 5.19 has the necessary infrastructure or the iunlink log item code this latest fix builds on top of. That was done to fix a whole class of relatively easy to hit O_TMPFILE related AGI-AGF-inode cluster buffer deadlocks. This fix avoids an entirely different class of inode cluster buffer deadlocks using the infrastructure introduced in the 5.19 deadlock fixes. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
