Re: Regression in generic/749 with 8k fsblock size on 6.18-rc1

[Kiryl Shutsemau <kirill@shutemov.name>]

On Wed, Oct 15, 2025 at 10:57:26AM -0700, Darrick J. Wong wrote:
> On Wed, Oct 15, 2025 at 04:59:03PM +0100, Kiryl Shutsemau wrote:
> > On Tue, Oct 14, 2025 at 10:52:14AM -0700, Darrick J. Wong wrote:
> > > Hi there,
> > > 
> > > On 6.18-rc1, generic/749[1] running on XFS with an 8k fsblock size fails
> > > with the following:
> > > 
> > > --- /run/fstests/bin/tests/generic/749.out	2025-07-15 14:45:15.170416031 -0700
> > > +++ /var/tmp/fstests/generic/749.out.bad	2025-10-13 17:48:53.079872054 -0700
> > > @@ -1,2 +1,10 @@
> > >  QA output created by 749
> > > +Expected SIGBUS when mmap() reading beyond page boundary
> > > +Expected SIGBUS when mmap() writing beyond page boundary
> > > +Expected SIGBUS when mmap() reading beyond page boundary
> > > +Expected SIGBUS when mmap() writing beyond page boundary
> > > +Expected SIGBUS when mmap() reading beyond page boundary
> > > +Expected SIGBUS when mmap() writing beyond page boundary
> > > +Expected SIGBUS when mmap() reading beyond page boundary
> > > +Expected SIGBUS when mmap() writing beyond page boundary
> > >  Silence is golden
> > > 
> > > This test creates small files of various sizes, maps the EOF block, and
> > > checks that you can read and write to the mmap'd page up to (but not
> > > beyond) the next page boundary.
> > > 
> > > For 8k fsblock filesystems on x86, the pagecache creates a single 8k
> > > folio to cache the entire fsblock containing EOF.  If EOF is in the
> > > first 4096 bytes of that 8k fsblock, then it should be possible to do a
> > > mmap read/write of the first 4k, but not the second 4k.  Memory accesses
> > > to the second 4096 bytes should produce a SIGBUS.
> > 
> > Does anybody actually relies on this behaviour (beyond xfstests)?
> 
> Beats me, but the mmap manpage says:
...
> POSIX 2024 says:
...
> From both I would surmise that it's a reasonable expectation that you
> can't map basepages beyond EOF and have page faults on those pages
> succeed.

<Added folks form the commit that introduced generic/749>

Modern kernel with large folios blurs the line of what is the page.

I don't want play spec lawyer. Let's look at real workloads.

If there's anything that actually relies on this SIGBUS corner case,
let's see how we can fix the kernel. But it will cost some CPU cycles.

If it only broke syntactic test case, I'm inclined to say WONTFIX.

Any opinions?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov