Re: [PATCH 1/1] xfs: fix overlapping extents returned for pNFS LAYOUTGET

[Christoph Hellwig <hch@infradead.org>]

On Wed, May 13, 2026 at 08:50:29AM -0700, Dai Ngo wrote:
> 
> On 5/13/26 12:01 AM, Christoph Hellwig wrote:
> > On Tue, May 12, 2026 at 10:21:53AM -0700, Dai Ngo wrote:
> > > A single LAYOUTGET request from the client can cause the server to
> > > issue multiple calls to xfs_fs_map_blocks() for different offsets
> > > within the same extent. Because the use of XFS_BMAPI_ENTIRE flag,
> > > these calls can produce overlapping mappings.
> > > 
> > > As a result, the LAYOUTGET reply sent to the NFS client may contain
> > > overlapping extents. This creates ambiguity in extent selection for a
> > > given file range, which can lead to incorrect device selection,
> > > inconsistent handling of datastate, and ultimately data corruption or
> > > protocol violations on the client side.
> > Please also add a check to the client that catches this and doesn't
> > use the layout that has extents outside the requested range.  And maybe
> > warn about it as well.
> 
> The returned extents cover exactly the range requested in the LAYOUTGET
> op. However these extents are overlapping. For example, here is the
> on-the-wire capture of the LAYOUTGET operation and reply showing the
> overlapping extents:

Now that is really weird.  How do we end up not using the remainder
of the previous extent from a previous nfsd4_block_map_extent call
in nfsd4_block_proc_layoutget?  Looks like there is another bug hiding
in the nfsd code somewhere.

And the client should probably also validate that extents of the same
kind do not overlap (read vs write extents are allowed to overlap).