linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Kiryl Shutsemau <kirill@shutemov.name>
Cc: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>,
	 Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	 "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	 Vlastimil Babka <vbabka@suse.cz>,
	Mike Rapoport <rppt@kernel.org>,
	 Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,  Rik van Riel <riel@surriel.com>,
	Harry Yoo <harry.yoo@oracle.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	 Shakeel Butt <shakeel.butt@linux.dev>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	 "Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	 linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 2/2] mm/truncate: Unmap large folio on split failure
Date: Wed, 29 Oct 2025 02:12:48 -0700 (PDT)	[thread overview]
Message-ID: <eaa8023f-f3e1-239d-a020-52f50df873e7@google.com> (raw)
In-Reply-To: <qte6322kbhn3xydiukyitgn73lbepaqlhqq43mdwhyycgdeuho@5b6wty5mcclt>

On Mon, 27 Oct 2025, Kiryl Shutsemau wrote:
> On Mon, Oct 27, 2025 at 03:10:29AM -0700, Hugh Dickins wrote:
...
> 
> > Aside from shmem/tmpfs, it does seem to me that this patch is
> > doing more work than it needs to (but how many lines of source
> > do we want to add to avoid doing work in the failed split case?):
> > 
> > The intent is to enable SIGBUS beyond EOF: but the changes are
> > being applied unnecessarily to hole-punch in addition to truncation.
> 
> I am not sure much it should apply to hole-punch. Filesystem folks talk
> about writing to a folio beyond round_up(i_size, PAGE_SIZE) being
> problematic for correctness. I have no clue if the same applies to
> writing to hole-punched parts of the folio.
> 
> Dave, any comments?
> 
> Hm. But if it is problematic it has be caught on fault. We don't do
> this. It will be silently mapped.

There are strict rules about what happens beyond i_size, hence this
patch.  But hole-punch has no persistent "i_size" to define it, and
silently remapping in a fresh zeroed page is the correct behaviour.

So the patch is making more work than is needed for hole-punch.

But I am thinking there of the view from above, from userspace.
If I think of the view from below, from the filesystem, then I'm
not at all sure how a filesystem is expected to deal with a failed
folio_split - and that goes beyond this patch, and therefore I
don't think it should concern you in this patch.

If a filesystem is asked to punch a hole, but mm cannot split the
folio which covers that hole, then page cache and filesystem are
left out of synch?  And if filesystem thinks one block has been
freed, and it's the last block in that filesystem, and it's then
given out to someone else, then our unsplit folio hides an ENOSPC?

Maybe this has all been well thought out, and each large folio
filesystem deals with it appropriately somehow; but I wouldn't
know, since a tmpfs is simply backed by its page cache.

Hugh

  reply	other threads:[~2025-10-29  9:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-23  9:32 [PATCHv2 0/2] Fix SIGBUS semantics with large folios Kiryl Shutsemau
2025-10-23  9:32 ` [PATCHv2 1/2] mm/memory: Do not populate page table entries beyond i_size Kiryl Shutsemau
2025-10-23 20:49   ` Andrew Morton
2025-10-23 20:54     ` David Hildenbrand
2025-10-23 21:36       ` Andrew Morton
2025-10-24  9:26         ` Kiryl Shutsemau
2025-10-26  4:54           ` Andrew Morton
2025-10-24 15:42   ` David Hildenbrand
2025-10-24 19:32     ` Kirill A. Shutemov
2025-10-27  9:34       ` David Hildenbrand
2025-10-27  8:20   ` Hugh Dickins
2025-10-27  9:14     ` Kiryl Shutsemau
2025-10-27  9:22     ` David Hildenbrand
2025-10-29  8:31       ` Hugh Dickins
2025-10-29 10:11         ` Kiryl Shutsemau
2025-10-30  5:59           ` Hugh Dickins
2025-10-30 17:08             ` Kiryl Shutsemau
2025-10-23  9:32 ` [PATCHv2 2/2] mm/truncate: Unmap large folio on split failure Kiryl Shutsemau
2025-10-23 20:56   ` Andrew Morton
2025-10-24  9:05     ` Kiryl Shutsemau
2025-10-24 15:43   ` David Hildenbrand
2025-10-27 10:10   ` Hugh Dickins
2025-10-27 10:38     ` David Hildenbrand
2025-10-27 10:40     ` Kiryl Shutsemau
2025-10-29  9:12       ` Hugh Dickins [this message]
2025-10-29 10:21         ` Kiryl Shutsemau
2025-10-29 15:19           ` Darrick J. Wong
2025-10-29 17:10             ` Kiryl Shutsemau
2025-10-23 17:47 ` [PATCHv2 0/2] Fix SIGBUS semantics with large folios Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eaa8023f-f3e1-239d-a020-52f50df873e7@google.com \
    --to=hughd@google.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=harry.yoo@oracle.com \
    --cc=kirill@shutemov.name \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).