undefined | Better HN

0 pointsavar3y ago0 comments

Interesting. That code will only need to the "stat" files of processes in userspace, so it's correct for its use-case.

But you're right that a more general parser would need to ignore what proc(5) has to say about the limit, and parse up to a limit of 64.

As far as I can tell the difference is because when you call prctl(2) with "PR_SET_NAME" it will get truncated to the "TASK_COMM_LEN" that proc(5) discusses. See this code in kernel/sys.c: https://github.com/torvalds/linux/blob/493ffd6605b2d3d4dc700...

This is the linux.git commit that changed it, before that kernel worker threads had to obey the same limit, it was first released with linux v4.18: https://github.com/torvalds/linux/commit/6b59808bfe482642287...

0 comments

jwilk3y ago

Your git commit message mentions PID reuse. Couldn't PID of a userspace process be reused by a kernel thread?

avarOP3y ago

Yes, you're right. It's been a while, I didn't think of that edge case.

For the purposes of that code it's still OK. It would read a kernel thread's file, fail to find the ending ")", and stop looking.

It's possible in principle that the kernel could a crafted kernel thread name that contained ")", followed by e.g. " X 12345 ". In that case I'd misinterpret that "12345" as the parent PID, and continue walking up that parent chain.

But in practice the kernel doesn't have, and is exceeding unlikely to have such "comm" fields.

Still, it's annoying that this was silently changed in v4.18 without a corresponding documentation update. It's easy to imagine C code written to assume its promises are true that would misbehave or segfault in the face of these longer kernel thread names.

Edit: I submitted linux-man patches to clarify this point: https://lore.kernel.org/linux-man/cover-0.2-000000000-202212...

j / k navigate · click thread line to collapse