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...
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.
As pointed out in https://news.ycombinator.com/item?id=34098360, and contrary to the proc(5) man page, this assumption is incorrect for kernel threads.