On Sat, 27 Aug 2022, Al Viro wrote: > 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. > It was mostly about avoiding code duplication. I'll see if I can find a cleaner way. Thanks, NeilBrown
