3 ms·

I noticed this around a year ago when writing a /proc/paid/stat parser for git (for logging the chain of parent processes). Here's that commit, it has a commen

• jwilk 4y ago
  > Finally the maximum length of the "comm" name itself is 15 characters As pointed out in https://news.ycombinator.com/item?id=34098360 https://news.ycombinator.com/item?id=34098360, and contrary to the proc(5) man page, this assumption is incorrect for kernel threads.
  • avar 4y ago
    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/493ffd6605b2d3d4dc7008ab927dba319f36671f/kernel/sys.c#L2407-L2414 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/6b59808bfe482642287ddf3fe9d4cccb10756652 https://github.com/torvalds/linux/commit/6b59808bfe482642287...
    • jwilk 4y ago
      Your git commit message mentions PID reuse. Couldn't PID of a userspace process be reused by a kernel thread?
      • avar 4y 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-20221223T174835Z-avarab@gmail.com/ https://lore.kernel.org/linux-man/cover-0.2-000000000-202212...