mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Zhu Jun <zhujun2@cmss.chinamobile.com>, akpm@linux-foundation.org
Cc: hannes@cmpxchg.org, ziy@nvidia.com, rostedt@goodmis.org,
	mhiramat@kernel.org, linux-mm@kvack.org,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+212c2d1f47994035cf7f@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm/compaction: Mark concurrent compact_considered accesses
Date: Wed, 11 Nov 2026 09:51:59 +0100	[thread overview]
Message-ID: <86bc9747-ad4b-4471-b507-dafe3b3cdb91@kernel.org> (raw)
In-Reply-To: <20261111084205.80997-1-zhujun2@cmss.chinamobile.com>

On 11/11/26 09:42, Zhu Jun wrote:
> Direct compaction and kcompactd update compact_considered without a
> common lock. KCSAN reports the plain increment racing with a reset.
> This counter is an approximate backoff heuristic and already permits
> concurrent increments to be lost.
> 
> Use a local snapshot for the saturating increment and mark all shared
> loads and stores, including the tracepoint snapshot. Preserve the
> existing saturation limit and deferral decisions.
> 
> Fixes: 4f92e2586b43 ("mm: compaction: defer compaction using an exponential backoff when compaction fails")
> Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>

Shouldn't KCSAN be suppressed by data_race() and not READ_ONCE/WRITE_ONCE?

> ---
>  include/trace/events/compaction.h |  2 +-
>  mm/compaction.c                   | 15 ++++++++-------
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/include/trace/events/compaction.h b/include/trace/events/compaction.h
> index d05759d18538..42303a4835f5 100644
> --- a/include/trace/events/compaction.h
> +++ b/include/trace/events/compaction.h
> @@ -255,7 +255,7 @@ DECLARE_EVENT_CLASS(mm_compaction_defer_template,
>  		__entry->nid = zone_to_nid(zone);
>  		__entry->idx = zone_idx(zone);
>  		__entry->order = order;
> -		__entry->considered = zone->compact_considered;
> +		__entry->considered = READ_ONCE(zone->compact_considered);
>  		__entry->defer_shift = zone->compact_defer_shift;
>  		__entry->order_failed = zone->compact_order_failed;
>  	),
> diff --git a/mm/compaction.c b/mm/compaction.c
> index f1b2060eb201..04b93d3545af 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -126,7 +126,7 @@ static unsigned long release_free_list(struct list_head *freepages)
>   */
>  static void defer_compaction(struct zone *zone, int order)
>  {
> -	zone->compact_considered = 0;
> +	WRITE_ONCE(zone->compact_considered, 0);
>  	zone->compact_defer_shift++;
>  
>  	if (order < zone->compact_order_failed)
> @@ -142,15 +142,16 @@ static void defer_compaction(struct zone *zone, int order)
>  static bool compaction_deferred(struct zone *zone, int order)
>  {
>  	unsigned long defer_limit = 1UL << zone->compact_defer_shift;
> +	unsigned long considered;
>  
>  	if (order < zone->compact_order_failed)
>  		return false;
>  
> -	/* Avoid possible overflow */
> -	if (++zone->compact_considered >= defer_limit) {
> -		zone->compact_considered = defer_limit;
> +	/* This is a heuristic; concurrent updates may be lost. */
> +	considered = READ_ONCE(zone->compact_considered) + 1;
> +	WRITE_ONCE(zone->compact_considered, min(considered, defer_limit));
> +	if (considered >= defer_limit)
>  		return false;
> -	}
>  
>  	trace_mm_compaction_deferred(zone, order);
>  
> @@ -166,7 +167,7 @@ void compaction_defer_reset(struct zone *zone, int order,
>  		bool alloc_success)
>  {
>  	if (alloc_success) {
> -		zone->compact_considered = 0;
> +		WRITE_ONCE(zone->compact_considered, 0);
>  		zone->compact_defer_shift = 0;
>  	}
>  	if (order >= zone->compact_order_failed)
> @@ -182,7 +183,7 @@ static bool compaction_restarting(struct zone *zone, int order)
>  		return false;
>  
>  	return zone->compact_defer_shift == COMPACT_MAX_DEFER_SHIFT &&
> -		zone->compact_considered >= 1UL << zone->compact_defer_shift;
> +		READ_ONCE(zone->compact_considered) >= 1UL << zone->compact_defer_shift;
>  }
>  
>  /* Returns true if the pageblock should be scanned for pages to isolate. */


      reply	other threads:[~2026-11-11  8:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  8:42 Zhu Jun
2026-11-11  8:51 ` Vlastimil Babka (SUSE) [this message]

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=86bc9747-ad4b-4471-b507-dafe3b3cdb91@kernel.org \
    --to=vbabka@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=syzbot+212c2d1f47994035cf7f@syzkaller.appspotmail.com \
    --cc=zhujun2@cmss.chinamobile.com \
    --cc=ziy@nvidia.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 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®