Eric, Am 17.05.2017 um 00:07 schrieb Eric Biggers: >>> I can reproduce this on an unencrypted directory after updating path_init() in >>> fs/namei.c to always clear LOOKUP_RCU, so that all path lookups are done in >>> ref-walk mode. So I think fscrypt_d_revalidate() was only relevant because it >>> causes all path lookups to drop out of rcu-walk mode. >> >> On ext4 or UBIFS? > > Both; the inode "leak" isn't filesystem-specific, beyond the fact that UBIFS > apparently limits the number of inodes on its orphan list while ext4 does not. > (How do I know it happens on ext4 then? /proc/slabinfo shows that lots of ext4 > inodes have been allocated, and after an unclean shutdown and remounting, it's > reported that 50,000+ orphan inodes were deleted.) UBIFS's orphan list is limited by the size of a LEB (logical erase block). With nandsim's default settings such a LEB is rather small and can store only 2k orphans. > There are lots of cases in which path lookups switch from rcu-walk mode into > ref-walk mode, so the fact that it was being caused by ->d_revalidate() in this > specific situation isn't really important, IMO. > > I think the actual fix would be something along the lines of making vfs_rmdir() > unhash any negative child dentries, so that they get "killed" by dput() later. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|