From: "Denis M. Karpov" <komlomal@gmail.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Pedro Falcato <pfalcato@suse.de>,
harry@kernel.org, akpm@linux-foundation.org,
Liam.Howlett@oracle.com, ljs@kernel.org, vbabka@kernel.org,
jannh@google.com, peterx@redhat.com, brauner@kernel.org,
viro@zeniv.linux.org.uk, jack@suse.cz, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
usama.arif@linux.dev
Subject: Re: [PATCH v2] userfaultfd: allow registration of ranges below mmap_min_addr
Date: Thu, 9 Apr 2026 18:54:08 +0300 [thread overview]
Message-ID: <CADtiZd0NF8=4YDs9YR6vKYK92SKYOFd0LR1R3w9ZNoZW4cy+jg@mail.gmail.com> (raw)
In-Reply-To: <adfDCpTH9n2lG63n@kernel.org>
On Thu, Apr 9, 2026 at 6:17 PM Mike Rapoport <rppt@kernel.org> wrote:
> On Thu, Apr 09, 2026 at 01:30:07PM +0100, Pedro Falcato wrote:
> > This looks relatively safe. However, I'm not sure if we want this in stable.
> > This has been broken for 11 years now, with no complaints.
>
> I believe Denis has a new usecase that wasn't there for those 11 years :)
>
> Denis, can you share more details about your usecase for us to better
> understand importance of backporting this to stable?
Hello Mike.
Actually, there is nothing new about the use case. We simply started using
UFFD instead of the classic mprotect approach in the binary translator to
track application writes. During development, we encountered this bug.
The translator cannot control where the translated application chooses
to map its
memory and if the app requires a low-address area, UFFD fails, whereas
mprotect would work just fine. I believe this is a genuine logic bug rather than
an improvement, and I would appreciate including the fix in stable.
next prev parent reply other threads:[~2026-04-09 15:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 10:33 Denis M. Karpov
2026-04-09 10:43 ` Lorenzo Stoakes
2026-04-09 11:56 ` Harry Yoo (Oracle)
2026-04-09 12:30 ` Pedro Falcato
2026-04-09 15:17 ` Mike Rapoport
2026-04-09 15:54 ` Denis M. Karpov [this message]
2026-04-09 15:13 ` Mike Rapoport
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='CADtiZd0NF8=4YDs9YR6vKYK92SKYOFd0LR1R3w9ZNoZW4cy+jg@mail.gmail.com' \
--to=komlomal@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=harry@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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