On Sat, Nov 02, 2019 at 06:08:42PM +0000, Al Viro wrote: > It is converging to a reasonably small and understandable surface, actually, > most of that being in core pathname resolution. Two big piles of nightmares > left to review - overlayfs and (somewhat surprisingly) setxattr call chains, > the latter due to IMA/EVM/LSM insanity... One thing found while digging through overlayfs (and responsible for several remaining pieces from the assorted pile): lookup_one_len_unlocked() calling conventions are wrong for its callers. Namely, 11 out of 12 callers really want ERR_PTR(-ENOENT) on negatives. Most of them take care to check, some rely upon that being impossible in their case. Interactions with dentry turning positive right after lookup_one_len_unlocked() has returned it are of varying bugginess... The only exception is ecryptfs, where we do lookup in the underlying fs on ecryptfs_lookup() and want to retain a negative dentry if we get one. Not sure what's the best way to handle that - it looks like we want a primitive with different behaviour on negatives, so the most conservative variant would be to add such, leaving lookup_one_len_unlocked() use for ecryptfs (and dealing with barriers properly in there), with everybody else switching to lookup_positive_unlocked(), or whatever we call that new primitive. Other variants: 1) add a primitve with existing lookup_one_len_unlocked() behaviour, changing lookup_one_len_unlocked() itselt to new calling conventions. Switch ecryptfs to that, drop now-useless checks from other callers. 2) get rid of pinning negative underlying dentries in ecryptfs. The cost will be doing lookup in underlying layer twice on something like mkdir(2), the second one quite likely served out of dcache. That would make _all_ callers of lookup_one_len_unlocked() need the same calling conventions. Preferences?
