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

[Kiryl Shutsemau <kirill@shutemov.name>]

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)?

I think this behaviour existed before the recent changes, but it was
less prominent.

Like, tmpfs with huge=always would fault-in PMD if there's order-9 folio
in page cache regardless of i_size.

See filemap_map_pages->filemap_map_pmd() path.

I believe the same happens for large folios in other filesystems.

Some of this behaviour is hidden by truncate path trying to split large
folios, split PMD and unmap a range of PTEs. But split can fail, so we
cannot rely on this for correctness.

I would like to understand more about expectations in real workload
before commit to a fix.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov