Re: [PATCH] xfs: annotate data race on li_lsn in CIL formatting vs AIL insertion

[Christoph Hellwig]

On Fri, Mar 20, 2026 at 10:55:07AM +0800, Cen Zhang wrote:
> Under simple interleaving on 64-bit architectures this is benign since
> li_lsn monotonically increases and both old/new values are valid
> checkpoint LSNs.  However, on 32-bit architectures the 64-bit xfs_lsn_t
> can be torn into two 32-bit loads, producing a bogus LSN that could
> cause log recovery to make incorrect replay decisions.  XFS already
> acknowledges this concern via the xfs_trans_ail_copy_lsn() helper which
> takes ail_lock on 32-bit.

Yes.

> Annotate with READ_ONCE()/WRITE_ONCE() to prevent compiler-level
> tearing on all architectures.

Well, xfs_trans_ail_copy_lsn pretty clearly documents that we actually
need a locak for the 32-bit case.  Assuming we don't have lock ordering
issues, using xfs_trans_ail_copy_lsn would be the right thing here.

> -	xfs_inode_to_log_dinode(ip, dic, ip->i_itemp->ili_item.li_lsn);
> +	xfs_inode_to_log_dinode(ip, dic, READ_ONCE(ip->i_itemp->ili_item.li_lsn));

.. and either way please avoid the overly long lines.