Re: [PATCH V5 7/9] dax: read holder_ops once in dax_holder_notify_failure()
From: John Groves
Date: Mon Jun 15 2026 - 09:22:52 EST
On 26/06/12 11:02AM, Richard Cheng wrote:
> On Thu, Jun 11, 2026 at 05:32:45PM +0800, John Groves wrote:
> > From: John Groves <John@xxxxxxxxxx>
> >
> > dax_holder_notify_failure() reads dax_dev->holder_ops twice without
> > READ_ONCE() -- once for the NULL check and once for the indirect
> > notify_failure() call. A concurrent fs_put_dax() or kill_dax() can clear
> > holder_ops between the two reads, so the check can observe a non-NULL
> > pointer while the call dereferences NULL.
> >
>
> Hello John,
>
> Thanks for this.
>
> Reviewed-by: Richard Cheng <icheng@xxxxxxxxxx>
>
> Small message nit, kill_dax() isn't a racing clearer.
Right -- kill_dax() clears holder_ops only after synchronize_srcu(), so it
can't race a reader under dax_read_lock(). Reworded the commit message and
the code comment for V6 to name only fs_put_dax().
> Plus I think this only fix holder_ops double-fetch, the fs_put_dax()
> race issue is separate and pre-existing.
Yes, intentionally -- this patch is just the reader-side double-fetch. The
fs_put_dax() race is the separate, pre-existing one handled by the next
patch in the series ("dax: fix holder_ops race in fs_put_dax()").
>
> Best regards,
> Richard Cheng.
Thanks,
John
<snip>