linux-kernel - Re: [PATCH v1] pid: annotate data-races around pid_ns->pid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <wdnzpfz4yh3oq6ikxne2zbyvkfzdvy7cuxeepwvoifff3esinf@4gct3653ajfh>
Date: Wed, 23 Apr 2025 18:24:53 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org, 
	mrpre@....com, syzbot+adcaa842b762a1762e7d@...kaller.appspotmail.com, 
	syzbot+fab52e3459fa2f95df57@...kaller.appspotmail.com, syzbot+0718f65353d72efaac1e@...kaller.appspotmail.com, 
	Andrew Morton <akpm@...ux-foundation.org>, Christian Brauner <brauner@...nel.org>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Suren Baghdasaryan <surenb@...gle.com>, Wei Yang <richard.weiyang@...il.com>, 
	David Hildenbrand <david@...hat.com>, Al Viro <viro@...iv.linux.org.uk>, 
	Mateusz Guzik <mjguzik@...il.com>, Joel Granados <joel.granados@...nel.org>, 
	Jens Axboe <axboe@...nel.dk>, Wei Liu <wei.liu@...nel.org>, 
	Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH v1] pid: annotate data-races around pid_ns->pid_allocated

On Wed, Apr 23, 2025 at 02:33:37PM +0000, Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:
> However, not all places that read/write pid_allocated are locked,
> for example:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/pid_namespace.c#n271
> https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/fork.c#n2602
> 
> So, in fact, the pidmap_lock is not effective. And if we were to add locks
> to all these places, it would be too heavy.
> 
> There's no actual impact on usage without locks, so I think it might be more
> suitable to add these macros, KASAN can recognize READ_ONCE and WRITE_ONCE
> and suppress warnings.

Wouldn't it be nicer to add data_race() to mark those places where the
race (presumably) doesn't matter? (Instead of _ONCE'ing places that are
under the lock.)

0.02€,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)