[ Coming back to this discussion because I today merged Tejun's
kworker tree for v4.18 ]
On Thu, May 17, 2018 at 5:17 AM Craig Small <csmall@xxxxxxxxxx> wrote:
>
> On Wed, May 16, 2018 at 01:13:03PM -0700, Linus Torvalds wrote:
> >
> > Adding Craig Small to the cc. A trivial one-liner to procps-ng fixes
> > things: changing the size of "cmd[]" in struct proc_t in proc/readproc.h
> > from 16 to 32 makes it just work:
>
> It seems most of the code just looks at the size of cmd and goes from
> there, so that is pretty simple change.
>
> Are you changing it to 32? I thought I saw the number 64 in one of the
> other emails. For user-facing programs like ps and top I think there is
> some sensible limit just for the sake of the human looking at it.
So right now we haven't changed the size of the in-kernel comm[] at
all, but I've merged Tejun's extended kworker naming, so despite
comm[] still being limited to 16 bytes, we actually return a string
that is longer than 16 bytes for comm[] in /proc for kworkers in
/proc/<pid>/status.
I think 32 will be "enough". And I don't mean that in any absolute
sense - because clearly people will always want more. But for the very
particular case of the kernel keeping a (small) buffer for process
naming when the full argv[] isn't accessible, I suspect 32 bytes is
reasonable.
After all, we've been making do with just 16 bytes for a quarter
century now (literally), so if we double it to 32, I guess we could be
ok for another longish time.
Again - this is just for the fallback case where you don't have a
_real_ command line.
So I'd ask that procps just change the "cmd[16]" array to "cmd[32]",
and that will work for our current "extended kworker info", and if we
at some point extend comm[] itself, it will be ok for that too.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
