mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
To: ljs@kernel.org
Cc: akpm@linux-foundation.org, david@kernel.org,
	lance.yang@linux.dev, liam@infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	mhocko@suse.com, pfalcato@suse.de, rppt@kernel.org,
	surenb@google.com, trintaeoitogc@gmail.com, vbabka@kernel.org,
	willy@infradead.org
Subject: Re: [PATCH] mm: bypass datarace check
Date: Wed,  9 Sep 2026 18:29:43 -0300	[thread overview]
Message-ID: <20260909212943.539665-1-trintaeoitogc@gmail.com> (raw)
In-Reply-To: <aqFWqqvUEiie8cYq@gremlin>

"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> 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.
I can be wrong, but was understand that due the order that the code was write
probably the data race problem will not happen.

The reader (__vmf_anon_prepare()):
```
if (likely(vma->anon_vma)) // lockless check
	return 0;              // OK

// if the check above fail

if (!__anon_vma_prepare(vma)) // called the __anon_vma_prepare
    return 0;

```

inside __anon_vma_prepare()
```
spin_lock(&mm->page_table_lock); //ACQUIRE semantics

if (likely(!vma->anon_vma)) // re-check under lock
    // ... alloc all

spin_unlock(&mm->page_table_lock);
```

This is safe because, if `if (likely(vma->anon_vma))` return NULL, we will got
the mmap_lock and then page_table_lock.

The critical re-check inside __anon_vma_prepare() happens under spin_lock(...)
with has ACQUIRE semantics.
With ACQUIRE semantics , the cpu (or compiler, I don't know) cannot reorder the
memory access acress the lock boundary.

I'm right?

> 
> 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!
ok, no problem

> 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
Hmm, is not the first time that any person points my english mistakes... I will
improve this point, thank you for yout jints

> > 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.
missing full stop, my bad.

> Needs a:
> 
> Suggested-by: Pedro Falcato <pfalcato@suse.de>
Yeah, I forget

> 
> 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:
I don't have installed any llm (not even cursor), I just use a deepseek,
chatgpt, etc.. to clear up a few questions. (maybe I should start use this to
help me with english too)

> There are other places where this check is done and etc.
I would should checked this, sorry. Anxiety.

Thanks Lorenzo for your review, help and patience 

  reply	other threads:[~2026-09-09 21:30 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)
2026-09-09 21:29   ` Guilherme Giacomo Simoes [this message]
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=20260909212943.539665-1-trintaeoitogc@gmail.com \
    --to=trintaeoitogc@gmail.com \
    --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=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=surenb@google.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®