Re: [PATCH] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 1 Dec 2024 at 06:17, Christian Brauner <brauner@kernel.org> wrote:
>
> /*
>  * Hold rcu lock to keep the name from being freed behind our back.
>  * Use cquire semantics to make sure the terminating NUL from
>  * __d_alloc() is seen.
>  *
>  * Note, we're deliberately sloppy here. We don't need to care about
>  * detecting a concurrent rename and just want a sensible name.
>  */

Sure. Note that even "sensible" isn't truly guaranteed in theory,
since a concurrent rename could be doing a "memcpy()" into the
dentry->d_name.name area at the same time on another CPU.

But "theoretically hard guarantees" isn't what this code cares about.

The only really hard rule is that the end result in comm[] needs to be
NUL-terminated at all times (and hey, even *that* is arguably a "don't
print garbage" rule rather than something truly fatal), and everything
else is "do the best you can".

Could we take the dentry lock to be really careful? Sure. We simply
don't care enough, and while other parts of execve() are much more
expensive, let's not.

              Linus