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
_
prev 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