On Sat, 08 Feb 2025, Al Viro wrote: > On Thu, Feb 06, 2025 at 04:42:45PM +1100, NeilBrown wrote: > > lookup_and_lock() combines locking the directory and performing a lookup > > prior to a change to the directory. > > Abstracting this prepares for changing the locking requirements. > > > > done_lookup_and_lock() provides the inverse of putting the dentry and > > unlocking. > > > > For "silly_rename" we will need to lookup_and_lock() in a directory that > > is already locked. For this purpose we add LOOKUP_PARENT_LOCKED. > > Ewww... I do realize that such things might appear in intermediate > stages of locking massage, but they'd better be _GONE_ by the end of it. > Conditional locking of that sort is really asking for trouble. > > If nothing else, better split the function in two variants and document > the differences; that kind of stuff really does not belong in arguments. > If you need it to exist through the series, that is - if not, you should > just leave lookup_one_qstr() for the "locked" case from the very beginning. That's what I did at first, but then when I realised I had to pass the lookup flags around everywhere.... Will revert. > > > This functionality is exported as lookup_and_lock_one() which takes a > > name and len rather than a qstr. > > ... for the sake of ...? nfsd. Thanks, NeilBrown
