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>
>
next prev parent 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