Re: [PATCH] mm/compaction: Mark concurrent compact_considered accesses

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] mm: data race in compaction_deferred() [1]
--

commit 065fba640e4d4df80527a642f4adcbe5f31c8683
Author: Zhu Jun <zhujun2@cmss.chinamobile.com>

mm/compaction: Mark concurrent compact_considered accesses

This commit marks concurrent reads and writes to zone->compact_considered
with READ_ONCE() and WRITE_ONCE() to avoid KCSAN data race reports.

> diff --git a/mm/compaction.c b/mm/compaction.c
> index a049415512c67..2ac6af7c1ee59 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;

[Severity: Medium]
This problem wasn't introduced by this patch, but should concurrent
accesses to zone->compact_defer_shift also be marked to avoid a data race
[1]?

Multiple CPUs performing page allocations under memory pressure call
defer_compaction(), compaction_deferred(), compaction_defer_reset(), and
compaction_restarting() concurrently without a common lock, reading and
updating zone->compact_defer_shift via plain C accesses.  This causes KCSAN
warnings and can corrupt compaction deferral limits.

[1] https://sashiko.dev/#/bug/linux-b61fd78e-8874-42f5-bbe1-bcd3914879cc

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111084205.80997-1-zhujun2@cmss.chinamobile.com?part=1