On Wed, Aug 27, 2025 at 02:32:49PM +0200, Christian Brauner wrote: > On Tue, Aug 26, 2025 at 11:39:17AM -0400, Josef Bacik wrote: > > We can end up with an inode on the LRU list or the cached list, then at > > some point in the future go to unlink that inode and then still have an > > elevated i_count reference for that inode because it is on one of these > > lists. > > > > The more common case is the cached list. We open a file, write to it, > > truncate some of it which triggers the inode_add_lru code in the > > pagecache, adding it to the cached LRU. Then we unlink this inode, and > > it exists until writeback or reclaim kicks in and removes the inode. > > > > To handle this case, delete the inode from the LRU list when it is > > unlinked, so we have the best case scenario for immediately freeing the > > inode. > > > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > > --- > > I'm not too fond of this particular change I think it's really misplaced > and the correct place is indeed drop_nlink() and clear_nlink(). > > I'm pretty sure that the number of callers that hold i_lock around > drop_nlink() and clear_nlink() is relatively small. So it might just be > preferable to drop_nlink_locked() and clear_nlink_locked() and just > switch the few places over to it. I think you have tooling to give you a > preliminary glimpse what and how many callers do this... Fair, I'll make the weird french guy figure it out. Thanks, Josef
