Re: [PATCH v4] ocfs2: cache the mount context for dentry lock callbacks

[Cen Zhang <zzzccc427@gmail.com>]

Hi Joseph,

Joseph Qi <joseph.qi@linux.alibaba.com> 于2026年10月23日周五 15:09写道：
>
> Don't see any difference between your v2 sent before.
> BTW, it seems v3 is also missing.
>
> Thanks,
> Joseph
>

Sorry for the confusion. I rechecked the early inode accesses you
pointed out in your v2 review:
https://lore.kernel.org/ocfs2-devel/018d8feb-2e63-4a73-ba36-10a5f94f3341@linux.alibaba.com/

My understanding is that these accesses have the following lifetime
protection:

- ocfs2_dentry_iput() keeps the VFS inode reference until after
  ocfs2_dentry_lock_put() returns. Lock teardown waits for QUEUED to
  clear if the worker is already running. The rename path likewise
  keeps the source dentry/inode alive while dropping the old dentry
  lock.
- A final put from ocfs2_dentry_post_unlock() runs synchronously on
  the same downconvert thread as the worker. Recursive processing
  from ocfs2_mark_lockres_freeing() sets FREEING before entering
  ocfs2_process_blocked_lock(), so the worker is skipped.

Thus the early access does not rely on the later extra-reference
check. A zero dl_count can still coexist with a live VFS inode
reference, and MAYBE_ORPHANED still needs to be set on that path for
local orphan cleanup.

The asynchronous DLM callbacks can overlap the final post-unlock
iput(), which is the separate lifetime window addressed by caching
osb.

I incorrectly moved the orphan marking past the extra-reference
check in v3. I reverted that change in v4, whose code is identical
to v2.

Does this analysis miss any path that could drop the last inode
reference while the worker can still access it?

Best regards,
Cen Zhang