mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Hildenbrand <david@kernel.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Jann Horn <jannh@google.com>,
	Pedro Falcato <pfalcato@suse.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 0/3] remove mmap_action success, error hooks
Date: Tue, 2 Jun 2026 13:10:49 -0700	[thread overview]
Message-ID: <20260602131049.74177bbb6d85fe01ff6512ff@linux-foundation.org> (raw)
In-Reply-To: <cover.1780397980.git.ljs@kernel.org>

On Tue,  2 Jun 2026 12:06:24 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:

> The mmap_action->success_hook was a strange beast added to enable code
> which appeared to absolutely require access to a VMA pointer to work
> correctly.
> 
> Primarily this was for hugetlb, however a different approach will be taken
> there, as clearly more work is required to figure out a sensible way of
> converting hugetlb to use mmap_prepare.
> 
> The other user was the memory char driver, specifically /dev/zero which has
> the unusual property of explicitly setting file-backed VMAs anonymous.
> 
> Providing the success hook was always foolish, as it allowed drivers a way
> to workaround the restriction that they should not access a pointer to a
> not-yet-correctly-initialised VMA - which defeats the purpose of the
> mmap_prepare work.
> 
> We can achieve the same thing in memory char driver without needing the
> success hook, so this series removes that, then removes the success hook
> altogether.
> 
> The error hook is also unnecessary - the motivation for this was for
> functions which need to override the error code when performing an mmap
> action in order to avoid breaking userspace.
> 
> We can achieve this by just providing a field for the error code. Doing
> this means we don't have to worry about the hook doing anything odd.
> 
> We also add a check to ensure the error code is in fact valid.
> 
> Again the memory char driver is the only current user of this, so this
> series updates it to use that.
> 
> After this change mmap_action has no custom hooks at all, which seems
> rather more cromulent than before.

Updated, thanks.

> v3:
> * Rename error_filter -> errror_override + update commit message as per
>  David.

Here's how v3 altered mm.git:

 drivers/char/mem.c              |    2 +-
 include/linux/mm_types.h        |    6 +++---
 mm/util.c                       |    6 +++---
 tools/testing/vma/include/dup.h |    6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

--- a/drivers/char/mem.c~b
+++ a/drivers/char/mem.c
@@ -357,7 +357,7 @@ static int mmap_mem_prepare(struct vm_ar
 
 	/* Remap-pfn-range will mark the range with the I/O flag. */
 	mmap_action_remap_full(desc, desc->pgoff);
-	desc->action.error_filter = -EAGAIN;
+	desc->action.error_override = -EAGAIN;
 
 	return 0;
 }
--- a/include/linux/mm_types.h~b
+++ a/include/linux/mm_types.h
@@ -844,10 +844,10 @@ struct mmap_action {
 	enum mmap_action_type type;
 
 	/*
-	 * If non-zero, filter errors that arise from mmap actions such that we
-	 * return error_filter instead. Only valid error codes may be specified.
+	 * If non-zero, replace errors that arise from mmap actions with this
+	 * value instead. Only valid error codes may be specified.
 	 */
-	int error_filter;
+	int error_override;
 
 	/*
 	 * This should be set in rare instances where the operation required
--- a/mm/util.c~b
+++ a/mm/util.c
@@ -1415,16 +1415,16 @@ static int mmap_action_finish(struct vm_
 	len = vma_pages(vma) << PAGE_SHIFT;
 	do_munmap(current->mm, vma->vm_start, len, NULL);
 
-	return action->error_filter ?: err;
+	return action->error_override ?: err;
 }
 
 #ifdef CONFIG_MMU
 
 static int check_mmap_action(struct mmap_action *action)
 {
-	const unsigned long filter = action->error_filter;
+	const unsigned long override = action->error_override;
 
-	if (WARN_ON_ONCE(filter && !IS_ERR_VALUE(filter)))
+	if (WARN_ON_ONCE(override && !IS_ERR_VALUE(override)))
 		return -EINVAL;
 
 	return 0;
--- a/tools/testing/vma/include/dup.h~b
+++ a/tools/testing/vma/include/dup.h
@@ -483,10 +483,10 @@ struct mmap_action {
 	enum mmap_action_type type;
 
 	/*
-	 * If non-zero, filter errors that arise from mmap actions such that we
-	 * return error_filter instead. Only valid error codes may be specified.
+	 * If non-zero, replace errors that arise from mmap actions with this
+	 * value instead. Only valid error codes may be specified.
 	 */
-	int error_filter;
+	int error_override;
 
 	/*
 	 * This should be set in rare instances where the operation required
_


      parent reply	other threads:[~2026-06-02 20:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02 11:06 Lorenzo Stoakes
2026-06-02 11:06 ` [PATCH v3 1/3] drivers/char/mem: eliminate unnecessary use of success_hook Lorenzo Stoakes
2026-06-03 16:25   ` Greg Kroah-Hartman
2026-06-11  7:56   ` Oscar Salvador (SUSE)
2026-06-02 11:06 ` [PATCH v3 2/3] mm/vma: remove mmap_action->success_hook Lorenzo Stoakes
2026-06-11  8:00   ` Oscar Salvador (SUSE)
2026-06-11  9:44     ` Lorenzo Stoakes
2026-06-02 11:06 ` [PATCH v3 3/3] mm/vma: eliminate mmap_action->error_hook, introduce error_override Lorenzo Stoakes
2026-06-02 12:05   ` David Hildenbrand (Arm)
2026-06-11  8:01   ` Oscar Salvador (SUSE)
2026-06-02 20:10 ` Andrew Morton [this message]

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=20260602131049.74177bbb6d85fe01ff6512ff@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=david@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.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

Powered by JetHome