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. > This functionality is exported as lookup_and_lock_one() which takes a > name and len rather than a qstr. ... for the sake of ...?
