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

Darrick J. Wong
2025-10-17T16:02:45Z

On Fri, Oct 17, 2025 at 03:28:32PM +0100, Kiryl Shutsemau wrote:
> On Fri, Oct 17, 2025 at 09:33:15AM +1100, Dave Chinner wrote:
> > On Thu, Oct 16, 2025 at 11:22:00AM +0100, Kiryl Shutsemau wrote:
> > > 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.
> >
> > Or, more importantly, consider the security-related implications of
> > the change....
> >
> > > 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?
> >
> > Mapping beyond EOF ranges into userspace address spaces is a
> > potential security risk. If there is ever a zeroing-beyond-EOF bug
> > related to large folios (history tells us we are *guaranteed* to
> > screw this up somewhere in future), then allowing mapping all the
> > way to the end of the large folio could expose a -lot more- stale
> > kernel data to userspace than just what the tail of a PAGE_SIZE
> > faulted region would expose.
>
> Could you point me to the details on a zeroing-beyond-EOF bug?
> I don't have context here.

Create a file whose size is neither aligned to PAGE_SIZE nor the fs
block size. The pagecache only maps full folios, so the last folio in
the pagecache will have EOF in the middle of it.

So what do you put in the folio beyond EOF? Most Linux filesystems
write zeroes to the post-EOF bytes at some point before writing the
block out to disk so that we don't persist random stale kernel memory.

Now you want to mmap that EOF folio into a userspace process. It was
stupid to allow that because the contents of the folio beyond EOF are
undefined. But we're stuck with this stupid API.

So now we need to zero the post-EOF folio contents before taking the
first fault on the mmap region, because we don't want the userspace
program to be able to load random stale kernel memory.

We also don't want programs to be able to store information in the mmap
region beyond EOF to prevent abuse, so writeback has to zero the post
EOF contents before writing the pagecache to disk.

> But if it is, as you saying, *guaranteed* to happen again, maybe we
> should slap __GFP_ZERO on page cache allocations? It will address the
> problem at the root.

Weren't you complaining upthread about spending CPU cycles? GFP_ZERO
on every page loaded into the pagecache isn't free either.

> Although, I think you are being dramatic about "*guaranteed*"...

He's not, post-EOF folio zeroing has broken in weird subtle ways every
1-2 years for the nearly 20 years I've worked in filesystems.

> If we solved problem of zeroing upto PAGE_SIZE border, I don't see
> why zeroing upto folio_size() border any conceptually different.
> Might require some bug squeezing, sure.

We already do that, but that's not the issue here.

The issue here is that you are *breaking* XFS behavior that is
documented in the mmap manpage. This worked as documented in 6.17, and
now it doesn't work.

--D

> --
> Kiryl Shutsemau / Kirill A. Shutemov
>