On Wed, May 16, 2018 at 7:28 PM Carlos O'Donell <carlos@xxxxxxxxxx> wrote:
> We are discussing increasing the size of comm[]. Should we discuss it in
the
> broader context of what kworkers need, *and* what userspaces server
processes
> might also use?
Don't even bother.
We already know that user processes want more than 4kB for command line.
Seriously. It's why proc_pid_cmdline_read() is such a mess. We tried to
make it much simpler, people complained.
People literally want to get the *whole* command line. Even though it can
be megabytes in size.
Tha fact is, "comm[]" is not that, and simply never will be. It is just the
basename of the executable, and even then it's truncated. Maybe it's
truncated to 16 bytes, maybe it might some day be truncated to a slightly
larger number, but it will never be what /proc/<pid>/cmdline people want.
> Today applications shuffle data around in arg/env pages to alter argv[0],
> but this is unreliable at best if your pages are already filled with
> arguments and environment variables.
The thing is, they don't just alter argv[0]. They sometimes alter a whole
lot more.
So don't think that this is about just argv[0], and about just
setproctitle(). And no, comm[] will *never* contain the whole argument list.
In theory, we could instead allow people to set the values of
mm->{arg,env}_{start,end}, which is where /proc/<pid>/cmdline actually
finds the argument array.
HOWEVER, there are serious issues with that too, and right now we only
allow it for checkpointing and PR_SET_MM_MAP prctl, which does a lot more
than that.
And it's entirely independent of tsk->comm[].
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
