Re: fsx failure on 3.10.0-rc1+ (xfstests 263) -- Mapped Read: non-zero data past EOF

[Dave Chinner <david@fromorbit.com>]

On Mon, Jun 10, 2013 at 09:17:31AM -0400, Brian Foster wrote:
> Hi guys,
> 
> I wanted to get this onto the list... I suspect this could be
> similar/related to the issue reported here:
> 
> http://oss.sgi.com/archives/xfs/2013-06/msg00066.html

Unlikely - generic/263 tests mmap IO vs direct IO, and Sage's
problem has neither...

> While running xfstests, the only apparent regression I hit from 3.9.0
> was generic/263. This test fails due to the following command (and
> resulting output):

Not a regression - 263 has been failing ever since it was introduced
in 2011 by:

commit 0d69e10ed15b01397e8c6fd7833fa3c2970ec024
Author: Christoph Hellwig <hch@infradead.org>
Date:   Mon Oct 10 18:22:16 2011 +0000

    split mapped writes vs direct I/O tests from 091
    
    This effectively reverts
    
        xfstests: add mapped write fsx operations to 091
    
    and adds a new test case for it.  It tests something slightly
    different, and regressions in existing tests due to new features
    are pretty nasty in a test suite.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>

It is testing mmap() writes vs direct IO, something that is known to
be fundamentally broken (i.e. racy) as mmap() page fault path does
not hold the XFS_IOLOCK or i_mutex in any way.  The direct IO path
tries to wark around this by flushing and invalidating cached pages
before IO submission, but the lack of locking in the page fault path
means we can't avoid the race entirely.

> P.S., I also came across the following thread which, if related,
> suggests this might be known/understood to a degree:
> 
> http://oss.sgi.com/archives/xfs/2012-04/msg00703.html

Yup, that's potentially one aspect of it. However, have you run the
test code on ext3/4? it works just fine - it's only XFS that has
problems with this case, so it's not clear that this is a DIO
problem. It was never able to work out where ext3/ext4 were zeroing
the part of the page beyond EOF, and I couldn't ever make the DIO
code reliably do the right thing. It's one of the reasons that lead
to this discussion as LSFMM:

http://lwn.net/Articles/548351/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs