Re: [PATCH 2/2] mm/truncate: Unmap large folio on split failure

[Kiryl Shutsemau <kirill@shutemov.name>]

On Tue, Oct 21, 2025 at 01:54:51PM +0200, David Hildenbrand wrote:
> On 21.10.25 13:31, Kiryl Shutsemau wrote:
> > On Tue, Oct 21, 2025 at 11:47:11AM +0200, David Hildenbrand wrote:
> > > On 21.10.25 11:44, David Hildenbrand wrote:
> > > > On 21.10.25 08:35, Kiryl Shutsemau wrote:
> > > > > From: Kiryl Shutsemau <kas@kernel.org>
> > > > > 
> > > > > Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are
> > > > > supposed to generate SIGBUS.
> > > > > 
> > > > > This behavior might not be respected on truncation.
> > > > > 
> > > > > During truncation, the kernel splits a large folio in order to reclaim
> > > > > memory. As a side effect, it unmaps the folio and destroys PMD mappings
> > > > > of the folio. The folio will be refaulted as PTEs and SIGBUS semantics
> > > > > are preserved.
> > > > > 
> > > > > However, if the split fails, PMD mappings are preserved and the user
> > > > > will not receive SIGBUS on any accesses within the PMD.
> > > > > 
> > > > > Unmap the folio on split failure. It will lead to refault as PTEs and
> > > > > preserve SIGBUS semantics.
> > > > 
> > > > Was the discussion on the old patch set already done? I can spot that
> > > > you send this series 20min after asking Dave
> > 
> > Based on feedback from Dave and Christoph on this patchset as well as
> > comments form Matthew and Darrick ont the report thread I see that my
> > idea to relax SIGBUS semantics for large folios will not fly :/
> 
> Then I was probably misreading the last email from you, likely the question
> you raised was independent of the progress of this series and more of
> general nature I assume.

Right.

> > 
> > But if you want to weigh in...
> 
> No, I think this makes sense. It's a regression that should be fixed.
> 
> > 
> > > Also, please send a proper patch series including cover letter that
> > > describes the changes since the last RFC.
> > 
> > There is no change besides Signed-off-bys.
> 
> Then point that out, please. It's common practice in MM to send cover
> letters for each new revision.
> 
> For example, Andrew will usually incorporate the cover letter into patch #1
> when merging.

Okay, will do.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov