All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 "David Hildenbrand (Arm)" <david@kernel.org>,
	Xuewen Wang <wangxuewen@kylinos.cn>,
	liam@infradead.org,  vbabka@kernel.org, jannh@google.com,
	chrisl@kernel.org, kasong@tencent.com,
	 shikemeng@huaweicloud.com, nphamcs@gmail.com,
	baoquan.he@linux.dev, baohua@kernel.org,  youngjun.park@lge.com,
	qi.zheng@linux.dev, shakeel.butt@linux.dev,
	 axelrasmussen@google.com, yuanchu@google.com,
	weixugc@google.com, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm: annotate data-race in cpu_needs_drain()
Date: Mon, 29 Jun 2026 19:20:06 +0100	[thread overview]
Message-ID: <akK2lkm1k6IF49ut@pedro-suse.lan> (raw)
In-Reply-To: <akKgikoi2dFKqmaG@lucifer>

On Mon, Jun 29, 2026 at 05:45:22PM +0100, Lorenzo Stoakes wrote:
> On Mon, Jun 29, 2026 at 09:34:02AM -0700, Andrew Morton wrote:
> > On Mon, 29 Jun 2026 11:23:26 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > > > >  		folio_batch_count(&fbatches->lru_lazyfree) ||
> > > > >  		folio_batch_count(&fbatches->lru_activate) ||
> > > > > -		need_mlock_drain(cpu) ||
> > > > > +		need_mlock_drain(cpu)) ||
> > > >
> > > > The indentation is a bit suboptimal now.
> > > >
> > > > Would read nicer as
> > > >
> > > > diff --git a/mm/swap.c b/mm/swap.c
> > > > index 588f50d8f1a8c..5958e6fdd3593 100644
> > > > --- a/mm/swap.c
> > > > +++ b/mm/swap.c
> > > > @@ -828,13 +828,13 @@ static bool cpu_needs_drain(unsigned int cpu)
> > > >         struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu);
> > > >
> > > >         /* Check these in order of likelihood that they're not zero */
> > > > -       return folio_batch_count(&fbatches->lru_add) ||
> > > > -               folio_batch_count(&fbatches->lru_move_tail) ||
> > > > -               folio_batch_count(&fbatches->lru_deactivate_file) ||
> > > > -               folio_batch_count(&fbatches->lru_deactivate) ||
> > > > -               folio_batch_count(&fbatches->lru_lazyfree) ||
> > > > -               folio_batch_count(&fbatches->lru_activate) ||
> > > > -               need_mlock_drain(cpu) ||
> > > > +       return data_race(folio_batch_count(&fbatches->lru_add) ||
> > > > +                        folio_batch_count(&fbatches->lru_move_tail) ||
> > > > +                        folio_batch_count(&fbatches->lru_deactivate_file) ||
> > > > +                        folio_batch_count(&fbatches->lru_deactivate) ||
> > > > +                        folio_batch_count(&fbatches->lru_lazyfree) ||
> > > > +                        folio_batch_count(&fbatches->lru_activate) ||
> > > > +                        need_mlock_drain(cpu)) ||
> > > >                 has_bh_in_lru(cpu, NULL);
> > >
> > > Yeah that works for me.
> > >
> > > Andrew - maybe easier if you fix that up? :)
> > >
> >
> > Sure.
> >
> > --- a/mm/swap.c~mm-annotate-data-race-in-cpu_needs_drain-fix
> > +++ a/mm/swap.c
> > @@ -832,12 +832,12 @@ static bool cpu_needs_drain(unsigned int
> >
> >  	/* Check these in order of likelihood that they're not zero */
> >  	return data_race(folio_batch_count(&fbatches->lru_add) ||
> > -		folio_batch_count(&fbatches->lru_move_tail) ||
> > -		folio_batch_count(&fbatches->lru_deactivate_file) ||
> > -		folio_batch_count(&fbatches->lru_deactivate) ||
> > -		folio_batch_count(&fbatches->lru_lazyfree) ||
> > -		folio_batch_count(&fbatches->lru_activate) ||
> > -		need_mlock_drain(cpu)) ||
> > +			 folio_batch_count(&fbatches->lru_move_tail) ||
> > +			 folio_batch_count(&fbatches->lru_deactivate_file) ||
> > +			 folio_batch_count(&fbatches->lru_deactivate) ||
> > +			 folio_batch_count(&fbatches->lru_lazyfree) ||
> > +			 folio_batch_count(&fbatches->lru_activate) ||
> > +			 need_mlock_drain(cpu)) ||
> >  		has_bh_in_lru(cpu, NULL);
> >  }
> >
> >
> > The removal of data_race() in need_mlock_drain() is a little worrisome
> > - perhaps any future callers would have needed it?
> >
> > need_mlock_drain() has only a single caller.  How about I remove it and
> > open-code it within cpu_needs_drain()?
> 
> That references a static per-CPU variable (mlock_fbatch) in mlock.c's
> compilation unit so I think it has to stay as it us unfortunately.
> 
> And it's better I think to only use the data_race() here where we definitely
> know we need it (and as the only instance of that).

I agree. FWIW something that would perhaps be nice to pull off would be:
lockdep_assert_held_or_data_race(), or something with a less excrutiating
name. Which could assert "either we hold a lock, or the caller is aware
that this can race". Which sounds nice. In that case, we could simply
slap that on need_mlock_drain() as requiring the mlock_fbatch's local lock,
or data_race().

It night be too special purpose though.

-- 
Pedro

  reply	other threads:[~2026-06-29 18:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  5:37 [PATCH v3] mm: annotate data-race in cpu_needs_drain() Xuewen Wang
2026-06-26  8:17 ` David Hildenbrand (Arm)
2026-06-29 10:23   ` Lorenzo Stoakes
2026-06-29 16:34     ` Andrew Morton
2026-06-29 16:45       ` Lorenzo Stoakes
2026-06-29 18:20         ` Pedro Falcato [this message]
2026-06-26  8:32 ` Pedro Falcato
2026-06-29 10:22 ` Lorenzo Stoakes

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=akK2lkm1k6IF49ut@pedro-suse.lan \
    --to=pfalcato@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baoquan.he@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=david@kernel.org \
    --cc=jannh@google.com \
    --cc=kasong@tencent.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=nphamcs@gmail.com \
    --cc=qi.zheng@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=shikemeng@huaweicloud.com \
    --cc=vbabka@kernel.org \
    --cc=wangxuewen@kylinos.cn \
    --cc=weixugc@google.com \
    --cc=youngjun.park@lge.com \
    --cc=yuanchu@google.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.