On Fri, Aug 26, 2022 at 12:10:43PM +1000, NeilBrown wrote: > When performing a "silly rename" to avoid removing a file that is still > open, we need to perform a lookup in a directory that is already locked. > > In order to allow common functions to be used for this lookup, introduce > LOOKUP_SILLY_RENAME which affirms that the directory is already locked > and that the vfsmnt is already writable. > > When LOOKUP_SILLY_RENAME is set, path->mnt can be NULL. As > i_op->rename() doesn't make the vfsmnt available, this is unavoidable. > So we ensure that a NULL ->mnt isn't fatal. This one is really disgusting. Flag-dependent locking is a pretty much guaranteed source of PITA and "magical" struct path is, again, asking for trouble. You seem to be trying for simpler call graph and you end up paying with control flow that is much harder to reason about.
