linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Ignacio Encinas <ignacio@iencinas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org,
	linux-kernel@vger.kernel.org,
	syzbot+419c4b42acc36c420ad3@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm: mark mm_struct.hiwater_rss as data racy
Date: Mon, 31 Mar 2025 12:48:54 +0100	[thread overview]
Message-ID: <2c15f7bf-7852-4aa5-98f1-c8604fe8fc00@lucifer.local> (raw)
In-Reply-To: <20250330-mm-maxrss-data-race-v1-1-2fe0ba6b8482@iencinas.com>

On Sun, Mar 30, 2025 at 02:02:04PM +0200, Ignacio Encinas wrote:
> mm_struct.hiwater_rss can be accessed concurrently without proper
> synchronization as reported by KCSAN.
>
> Given that this just provides accounting information and that the extra
> accuracy isn't worth the potential slowdown, let's annotate is
> __data_racy to make KCSAN happy.
>
> Reported-by: syzbot+419c4b42acc36c420ad3@syzkaller.appspotmail.com

You'll want a:
Closes: https://lore.kernel.org/all/67e3390c.050a0220.1ec46.0001.GAE@google.com/

Here too.

> Suggested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Signed-off-by: Ignacio Encinas <ignacio@iencinas.com>

Thanks for this, but I don't think this patch works, see below for a
suggested alternative approach.

> ---
> Similar issues have been solved in the past [1]. An actual analysis of
> the data race can be found in [2] and [3].
>
> Lorenzo, I added the Suggested-by as your proposal seems roughly
> equivalent to what I propose.

Sure no problem!

>
> [1] https://lore.kernel.org/all/20210913105550.1569419-1-liupeng256@huawei.com/T/#u
> [2] https://lore.kernel.org/all/900c5035-865d-40b7-8d55-0cbbbc059294@lucifer.local/
> [3] https://lore.kernel.org/linux-mm/iwtvhos74gwrk5v5szlosnkusxqp6ubqy6ytkclkucbjwdw4zr@bwxyrwcnybbz/
> ---
>  include/linux/mm_types.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 0234f14f2aa6bea42a8a62ccb915c94f556cd3cc..84c86951a978aad07ab4ecefbfff77e7418d8402 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -19,6 +19,7 @@
>  #include <linux/workqueue.h>
>  #include <linux/seqlock.h>
>  #include <linux/percpu_counter.h>
> +#include <linux/compiler_types.h>
>
>  #include <asm/mmu.h>
>
> @@ -939,7 +940,7 @@ struct mm_struct {
>  #endif
>
>
> -		unsigned long hiwater_rss; /* High-watermark of RSS usage */
> +		unsigned long __data_racy hiwater_rss; /* High-watermark of RSS usage */

This translates to volatile if KCSAN is enabled, and I really don't want to
apply that unnecessarily given the impliciations/any weirdness we might
observe as a result that might be confounding.

I also don't want to _across the board_ say 'hey we don't care about races
for this'.

I think use of data_race() would make more sense.

Probably we're fine doing this in update_hiwater_rss(), so something like:

static inline void update_hiwater_rss(struct mm_struct *mm)
{
	unsigned long _rss = get_mm_rss(mm);

	if (data_race(mm->hiwater_rss) < _rss)
		mm->hiwater_rss = _rss;
}

This labels it as 'we don't care', is a no-op if KCSAN is disabled and
abstracts the decision to this specific point.

Cheers, Lorenzo


>  		unsigned long hiwater_vm;  /* High-water virtual memory usage */
>
>  		unsigned long total_vm;	   /* Total pages mapped */
>
> ---
> base-commit: 3571e8b091f4270d869dda7a6cc43616c6ad6897
> change-id: 20250315-mm-maxrss-data-race-6ce86b0deb14
>
> Best regards,
> --
> Ignacio Encinas <ignacio@iencinas.com>
>


  reply	other threads:[~2025-03-31 15:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-30 12:02 Ignacio Encinas
2025-03-31 11:48 ` Lorenzo Stoakes [this message]
2025-03-31 18:08   ` Ignacio Encinas Rubio

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=2c15f7bf-7852-4aa5-98f1-c8604fe8fc00@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=ignacio@iencinas.com \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=skhan@linuxfoundation.org \
    --cc=syzbot+419c4b42acc36c420ad3@syzkaller.appspotmail.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