Re: [PATCH RFC] ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write()

On Fri, May 29, 2026 at 7:31 PM 'syzbot' via
syzkaller-upstream-moderation
<[email protected]> wrote:
>
> A circular locking dependency can occur involving three OCFS2 system inode
> locks: INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and
> ORPHAN_DIR_SYSTEM_INODE.
>
> The circular dependency is formed by three separate code paths. First, in
> ocfs2_mknod(), the code reserves an inode by acquiring the
> INODE_ALLOC_SYSTEM_INODE lock, and then reserves metadata blocks by
> acquiring the EXTENT_ALLOC_SYSTEM_INODE lock. Second, in
> ocfs2_dio_end_io_write(), the code allocates metadata blocks for unwritten
> extents, acquiring the EXTENT_ALLOC_SYSTEM_INODE lock. Later in the same
> function, if the inode was orphaned, it calls
> ocfs2_del_inode_from_orphan(), which acquires the ORPHAN_DIR_SYSTEM_INODE
> lock. The allocation context is only freed at the end of the function,
> meaning the EXTENT_ALLOC_SYSTEM_INODE lock is held while
> ORPHAN_DIR_SYSTEM_INODE is acquired. Third, in ocfs2_wipe_inode(), the
> ORPHAN_DIR_SYSTEM_INODE lock is acquired first to prevent races with
> recovery completion, and then it calls ocfs2_remove_inode(), which acquires
> the INODE_ALLOC_SYSTEM_INODE lock to free the inode.
>
> This patch breaks the cycle by addressing the dependency in
> ocfs2_dio_end_io_write(). The data_ac and meta_ac allocation contexts are
> only needed for the transaction that marks the extents as written. Once the
> transaction is committed and the allocation semaphore is released, these
> contexts are no longer needed. We can safely free them, which releases the
> EXTENT_ALLOC_SYSTEM_INODE lock, before calling
> ocfs2_del_inode_from_orphan(). This ensures that the
> EXTENT_ALLOC_SYSTEM_INODE lock is dropped before we attempt to acquire the
> ORPHAN_DIR_SYSTEM_INODE lock, successfully breaking the circular
> dependency.

Let's rework the description a bit.
Include the original bug report (drop the irrelevant parts) listing
the stack traces of the circular lock chain parts. Still keep some
explanations of the existing code, but make it a bit shorter then.

>
> Fixes: d647c5b2fbf8 ("ocfs2: split transactions in dio completion to avoid credit exhaustion")
> Assisted-by: Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: [email protected]
> Closes: https://syzkaller.appspot.com/bug?extid=b225d4dfce6219600c42
> Link: https://syzkaller.appspot.com/ai_job?id=c86e9953-fff6-40ca-b2f0-eff12366a33a
> To: "Joel Becker" <[email protected]>
> To: "Joseph Qi" <[email protected]>
> To: "Mark Fasheh" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
>
> ---
> diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
> index 6ec198bda..4acdbb708 100644
> --- a/fs/ocfs2/aops.c
> +++ b/fs/ocfs2/aops.c
> @@ -2372,6 +2372,15 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
>  unlock:
>         up_write(&oi->ip_alloc_sem);
>
> +       if (data_ac) {
> +               ocfs2_free_alloc_context(data_ac);
> +               data_ac = NULL;
> +       }
> +       if (meta_ac) {
> +               ocfs2_free_alloc_context(meta_ac);
> +               meta_ac = NULL;
> +       }
> +
>         /* everything looks good, let's start the cleanup */
>         if (!ret && dwc->dw_orphaned) {
>                 BUG_ON(dwc->dw_writer_pid != task_pid_nr(current));
> @@ -2383,10 +2392,6 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
>         ocfs2_inode_unlock(inode, 1);
>         brelse(di_bh);
>  out:
> -       if (data_ac)
> -               ocfs2_free_alloc_context(data_ac);
> -       if (meta_ac)
> -               ocfs2_free_alloc_context(meta_ac);
>         ocfs2_run_deallocs(osb, &dealloc);
>         ocfs2_dio_free_write_ctx(inode, dwc);
>
>
>
> base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
> --
> This is an AI-generated patch subject to moderation.
> Reply with '#syz upstream' to Sign-off the patch as a human author
> and send it to the upstream kernel mailing lists.
> Reply with '#syz reject' to reject it ('#syz unreject' to undo).
>
> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.
> syzbot engineers can be reached at [email protected].
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-upstream-moderation" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/008b2675-2e48-4150-a1ec-e68026253bad%40mail.kernel.org.