linux-kernel - Re: [GIT PULL] tracing: Fixes for v6.17

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: <CAHk-=wi0c5oBqQiZctP1SYAW7XGHYEDchJWBUSXvQA-XGmNk3w@mail.gmail.com>
Date: Wed, 10 Sep 2025 12:19:44 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Guenter Roeck <linux@...ck-us.net>, 
	Luo Gengkun <luogengkun@...weicloud.com>, Pu Lehui <pulehui@...wei.com>, 
	Qianfeng Rong <rongqianfeng@...o.com>, Vladimir Riabchun <ferr.lambarginio@...il.com>, 
	Wang Liang <wangliang74@...wei.com>
Subject: Re: [GIT PULL] tracing: Fixes for v6.17

On Tue, 9 Sept 2025 at 13:21, Steven Rostedt <rostedt@...dmis.org> wrote:
>
>         Back in 2016, the get_user_pages_fast() and
>   the kmap() logic was replaced by a __copy_from_user_inatomic(). But the
>   _inatomic() is somewhat a misnomer, as if the data being read faults, it can
>   cause a schedule. This is not something you want to do in an atomic context.

Somebody is very very confused, and this "explanation" is just wrong
and entirely misleading.

__copy_from_user_inatomic() is very much atomic. But it is - as the
dual underscores indicate - a *HELPER* function that needs the caller
to do the appropriate coding around it.

In this case, the appropriate coding is to typically surround it with
a pagefault_{disable,enable}() pattern to let the page faulting code
know to not actually do the fault.

You also need to actually verify that the user address is valid - as
is typical with all the double-undercore user access functions.

>   Since the time this was added, copy_from_user_nofault() was added which is
>   what is actually needed here. Replace the inatomic() with the nofault().

I'm not disagreeing with the change, because that "nofault()" helper
(without the double underscores) does do all the "appropriate coding
around it".

And then it actually *uses* __copy_from_user_inatomic() to do the copy
- because that function really is meant for atomic contents.

So that explanation really is very very wrong and entirely confused.

Because it was never about __copy_from_user_inatomic() not being
appropriate from atomic context. It was about the tracing code
apparently just using it wrong.

               Linus