From: Oleg Nesterov <oleg@redhat.com>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christian Brauner <brauner@kernel.org>,
David Hildenbrand <david@kernel.org>,
Jann Horn <jannh@google.com>, Kees Cook <kees@kernel.org>,
Michal Hocko <mhocko@suse.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Liam R. Howlett" <liam@infradead.org>
Subject: Re: [PATCH v2] mm_access: simplify the security checks
Date: Mon, 1 Jun 2026 14:42:30 +0200 [thread overview]
Message-ID: <ah1-NmlbYsdH3hJp@redhat.com> (raw)
In-Reply-To: <ah1qeNkatqx_N93-@lucifer>
On 06/01, Lorenzo Stoakes wrote:
>
> +cc Liam for mm lifecycle stuff :)
>
> The subject here seems not quite right - you're adding complexity here in that
> now there's a racey fast path.
OK. See my reply to David. If it doesn't look like a simplification -
lets forget this patch ;)
> One behavioural change here though is that down_read_killable() was used
> previously, so such a situation would return -EINTR, but now would instead
> succeed.
I don't really follow... SIGKILL from de_thread() or anything else can
come right after down_read_killable().
> > All we need for correctness is READ_ONCE() to ensure the compiler
> > won't reload task->mm. This is not enough for KCSAN, but we already
>
> I'm not sure 'this is not enough for KCSAN' is really reassuring :)
If I understand correctly KCSAN will complain if (say) we race with the
exiting task which does current->mm = NULL without WRITE_ONCE in exit_mm().
> It's useful to put a revision history (ideally with links to prior revisions)
> below the --- line to explain how vN differs from v(N-1).
Yes... I didn't do it this time because V2 doesn't differ from V1, I just removed
the duplicated paragraph from the changelog.
> Overall I'm not really convinced about this patch - this isn't simplifying
> things, it's introducing subtle assumptions and I don't really see the
> benefit?
Thanks for review! lets forget this patch then.
Oleg.
next prev parent reply other threads:[~2026-06-01 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 13:56 [PATCH] mm_access: simplify the security checks Oleg Nesterov
2026-05-30 14:10 ` Oleg Nesterov
2026-06-01 11:16 ` Lorenzo Stoakes
2026-05-30 14:12 ` [PATCH v2] " Oleg Nesterov
2026-06-01 12:04 ` David Hildenbrand (Arm)
2026-06-01 12:31 ` Oleg Nesterov
2026-06-01 12:12 ` Lorenzo Stoakes
2026-06-01 12:42 ` Oleg Nesterov [this message]
2026-05-30 15:00 ` [PATCH] " Oleg Nesterov
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=ah1-NmlbYsdH3hJp@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.