[PATCHv2 0/2] Fix SIGBUS semantics with large folios

Kiryl Shutsemau posted 2 patches 3 months, 2 weeks ago
There is a newer version of this series
mm/filemap.c  | 18 ++++++++++--------
mm/memory.c   | 13 +++++++++++--
mm/truncate.c | 31 +++++++++++++++++++++++++------
3 files changed, 46 insertions(+), 16 deletions(-)
[PATCHv2 0/2] Fix SIGBUS semantics with large folios
Posted by Kiryl Shutsemau 3 months, 2 weeks ago
From: Kiryl Shutsemau <kas@kernel.org>

Accessing memory within a VMA, but beyond i_size rounded up to the next
page size, is supposed to generate SIGBUS.

Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749
failed due to missing SIGBUS. This was caused by my recent changes that
try to fault in the whole folio where possible:

        19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()")
        357b92761d94 ("mm/filemap: map entire large folio faultaround")

These changes did not consider i_size when setting up PTEs, leading to
xfstest breakage.

However, the problem has been present in the kernel for a long time -
since huge tmpfs was introduced in 2016. The kernel happily maps
PMD-sized folios as PMD without checking i_size. And huge=always tmpfs
allocates PMD-size folios on any writes.

I considered this corner case when I implemented a large tmpfs, and my
conclusion was that no one in their right mind should rely on receiving
a SIGBUS signal when accessing beyond i_size. I cannot imagine how it
could be useful for the workload.

But apparently filesystem folks care a lot about preserving strict
SIGBUS semantics.

Generic/749 was introduced last year with reference to POSIX, but no
real workloads were mentioned. It also acknowledged the tmpfs deviation
from the test case.

POSIX indeed says[3]:

        References within the address range starting at pa and
        continuing for len bytes to whole pages following the end of an
        object shall result in delivery of a SIGBUS signal.

The patchset fixes the regression introduced by recent changes as well
as more subtle SIGBUS breakage due to split failure on truncation.

v2:
 - Fix try_to_unmap() flags;
 - Add warning if try_to_unmap() fails to unmap the folio;
 - Adjust comments and commit messages;
 - Whitespace fixes;
v1:
 - Drop RFC;
 - Add Signed-off-bys;

[1] https://lore.kernel.org/all/20251014175214.GW6188@frogsfrogsfrogs
[2]
https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/tests/generic/749?h=for-next&id=e4a6b119e5
229599eac96235fb7e683b8a8bdc53
[3] https://pubs.opengroup.org/onlinepubs/9799919799/
Kiryl Shutsemau (2):
  mm/memory: Do not populate page table entries beyond i_size
  mm/truncate: Unmap large folio on split failure

 mm/filemap.c  | 18 ++++++++++--------
 mm/memory.c   | 13 +++++++++++--
 mm/truncate.c | 31 +++++++++++++++++++++++++------
 3 files changed, 46 insertions(+), 16 deletions(-)

-- 
2.50.1
Re: [PATCHv2 0/2] Fix SIGBUS semantics with large folios
Posted by Darrick J. Wong 3 months, 2 weeks ago
On Thu, Oct 23, 2025 at 10:32:49AM +0100, Kiryl Shutsemau wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
> 
> Accessing memory within a VMA, but beyond i_size rounded up to the next
> page size, is supposed to generate SIGBUS.
> 
> Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749
> failed due to missing SIGBUS. This was caused by my recent changes that
> try to fault in the whole folio where possible:
> 
>         19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()")
>         357b92761d94 ("mm/filemap: map entire large folio faultaround")
> 
> These changes did not consider i_size when setting up PTEs, leading to
> xfstest breakage.
> 
> However, the problem has been present in the kernel for a long time -
> since huge tmpfs was introduced in 2016. The kernel happily maps
> PMD-sized folios as PMD without checking i_size. And huge=always tmpfs
> allocates PMD-size folios on any writes.
> 
> I considered this corner case when I implemented a large tmpfs, and my
> conclusion was that no one in their right mind should rely on receiving
> a SIGBUS signal when accessing beyond i_size. I cannot imagine how it
> could be useful for the workload.
> 
> But apparently filesystem folks care a lot about preserving strict
> SIGBUS semantics.
> 
> Generic/749 was introduced last year with reference to POSIX, but no
> real workloads were mentioned. It also acknowledged the tmpfs deviation
> from the test case.
> 
> POSIX indeed says[3]:
> 
>         References within the address range starting at pa and
>         continuing for len bytes to whole pages following the end of an
>         object shall result in delivery of a SIGBUS signal.
> 
> The patchset fixes the regression introduced by recent changes as well
> as more subtle SIGBUS breakage due to split failure on truncation.
> 

This fixes generic/749 for me, thanks!
Tested-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> v2:
>  - Fix try_to_unmap() flags;
>  - Add warning if try_to_unmap() fails to unmap the folio;
>  - Adjust comments and commit messages;
>  - Whitespace fixes;
> v1:
>  - Drop RFC;
>  - Add Signed-off-bys;
> 
> [1] https://lore.kernel.org/all/20251014175214.GW6188@frogsfrogsfrogs
> [2]
> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/tests/generic/749?h=for-next&id=e4a6b119e5
> 229599eac96235fb7e683b8a8bdc53
> [3] https://pubs.opengroup.org/onlinepubs/9799919799/
> Kiryl Shutsemau (2):
>   mm/memory: Do not populate page table entries beyond i_size
>   mm/truncate: Unmap large folio on split failure
> 
>  mm/filemap.c  | 18 ++++++++++--------
>  mm/memory.c   | 13 +++++++++++--
>  mm/truncate.c | 31 +++++++++++++++++++++++++------
>  3 files changed, 46 insertions(+), 16 deletions(-)
> 
> -- 
> 2.50.1
> 
>