From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
Cc: akpm@linux-foundation.org, david@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, pfalcato@suse.de, willy@infradead.org,
lance.yang@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: bypass datarace check
Date: Wed, 9 Sep 2026 14:44:06 +0100 [thread overview]
Message-ID: <aqFWqqvUEiie8cYq@gremlin> (raw)
In-Reply-To: <20260909115723.528501-1-trintaeoitogc@gmail.com>
I started review below but honestly this patch is confused in multiple ways
and it's not entirely clear you really understand what's going on here.
It's also basically implementing what we suggested.
So at this point I think it's easier if I send the patch with a:
Reported-by:
Closes:
tag -> you, this patch.
Thanks!
On Wed, Sep 09, 2026 at 08:57:23AM -0300, Guilherme Giacomo Simoes wrote:
> Despiste kcsan point to a possible race condition problem, this is a
Typos -> Despite, point -> points
> safe race condition due the access memory ordering, since
> spin_lock(&mm->page_table_lock) have ACQUIRE semantics and ensure the
> ordering mapping.
This sentence is a bit confused. Acquire semantics mean absolutely nothing
unless paired with another operation and etc. etc.
>
> Create a new function called vma_is_faulted(), that return a
> data_race(vma->anon_vma) to bypass kcsan
This sentence reads incomplete? Or missing full stop?
>
Needs a:
Suggested-by: Pedro Falcato <pfalcato@suse.de>
Also:
Assisted-by: LLM?
The list below reads very LLM-ish so I have to ask did you use one etc. etc.
https://docs.kernel.org/process/coding-assistants.html
Perhaps given I am suggesting a lot here a:
> Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
> ---
> mm/memory.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 6b8280cfc1db..d85d67927400 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3800,6 +3800,25 @@ static inline vm_fault_t vmf_can_call_fault(const struct vm_fault *vmf)
> return VM_FAULT_RETRY;
> }
>
> +/**
> + * vma_is_faulted - check if a vma has been faulted
Would rather 'has @vma been faulted in?'
> + * @vma: the vma to check
> + *
> + * This is a lockless access that may race with __anon_vma_prepare().
This doesn't belong here. In fact it doesn't belong at all IMO.
> + * The race is safe because:
There isn't a race at all it's KCSAN getting confused because it can't prove
that there isn't.
> + * - The fault handler ensures that the mapping of memory is ordered.
What has that got to do with this function?
> + * - If we read NULL, the caller will re-check
Umm, no? This function doesn't force callers to re-check?
> + * - The page_table_lock provides ACQUIRE semantics for memory ordering
I'm not sure how this relates to anything but again this doesn't really belong
here.
Anyway let's drop all of this please.
> + *
> + * Return: true if vma->anon_vma is non-NULL, false otherwise
This is completely breaking the abstraction.
'true if the VMA is faulted in, otherwise false.'
> + */
> +static inline bool vma_is_faulted(const struct vm_area_struct *vma)
Why in memory.c and why inline if it's in a .c file? This belongs in mm.h with other such helpers.
> +{
> + /* Lockless check - safe because we re-validate under page_table_lock */
You don't need a comment saying accessing a field esp. with data_race() is
lockless, that's implied...
Maybe:
/* Benign, see __anon_vma_prepare(). */
> + return data_race(vma->anon_vma);
> +}
> +
> +
> /**
> * __vmf_anon_prepare - Prepare to handle an anonymous fault.
> * @vmf: The vm_fault descriptor passed from the fault handler.
> @@ -3819,8 +3838,7 @@ vm_fault_t __vmf_anon_prepare(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> vm_fault_t ret = 0;
> -
> - if (likely(vma->anon_vma))
> + if (likely(vma_is_faulted(vma)))
> return 0;
There are other places where this check is done and etc.
> if (vmf->flags & FAULT_FLAG_VMA_LOCK) {
> if (!mmap_read_trylock(vma->vm_mm))
> --
> 2.52.0
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-09-09 13:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 11:57 Guilherme Giacomo Simoes
2026-09-09 13:44 ` Lorenzo Stoakes (ARM) [this message]
2026-09-09 21:29 ` Guilherme Giacomo Simoes
2026-09-10 9:20 ` Lorenzo Stoakes (ARM)
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=aqFWqqvUEiie8cYq@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=trintaeoitogc@gmail.com \
--cc=vbabka@kernel.org \
--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
all inboxes | Powered by JetHome®