Rationale for setting COMMLEN to 19 in struct kinfo_proc

[John Baldwin]

-- 
John Baldwin
On 5/29/18 8:16 PM, Brooks Davis wrote:
> On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote:
>> Hello.
>>
>> I've been debugging a failing Qt (KDE, to be precise) test and found that
>> process name returned in kinfo_proc structure gets truncated to 19 symbols.
>> This causes other errors in the application. I'm wondering why is this
>> field so small and is there possibility to increase it? I think, having
>> applications with names longer than 19 characters is not that rare.
>>
>> Relevant header: /usr/include/sys/user.h
>>
>> Simple testcase to feature the problem:
>>
>> # cat k.cpp
>> #include <sys/types.h>
>> #include <signal.h>
>> #include <unistd.h>
>> #include <stdio.h>
>>
>> #include <sys/cdefs.h>
>> #include <sys/param.h>
>> #include <sys/sysctl.h>
>> #include <sys/user.h>
>>
>> int main()
>> {
>>     auto pid = getpid();
>>     struct kinfo_proc kp;
>>     int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid };
>>
>>     size_t len = sizeof(kp);
>>     u_int mib_len = sizeof(mib)/sizeof(u_int);
>>
>>     if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0)
>>         return -1;
>>
>>     puts(kp.ki_tdname);
>>     puts(kp.ki_comm);
>>
>>     return 0;
>> }
>> # c++ -o abcdefghijklmnopqrstuvwxyz
>> # ./abcdefghijklmnopqrstuvwxyz
>> abcdefghijklmnop
>> abcdefghijklmnopqrs
> 
> Changing the size of fields in kinfo_proc would be enormously
> disruptive.  Take a look at all the source that uses KERN_PROC_PID for a
> subset of things that would break.
> 
> Sometimes we can break these interfaces, but I think this one would
> require new sysctl mibs.  If we did that we should come up with an
> interface that is identical between 32-bit and 32-bit systems and
> doesn't export pointers.

p_comm[] in struct proc is only 20 bytes long (19 chars + nul), so you
can't make it bigger in kinfo_proc anyway as we only store 19 chars
in the kernel.  (Note that we do have room to grow char arrays if
needed without having to completely rototill though; we use a hack to
store the "rest" of the thread name in a separate array to export the
full 19 chars of the thread name now.)

If you want the raw command line you can't get that via kinfo_proc.
You can use the kern.proc.args sysctl or wrapper functions like
kvm_getargv() or procstat_getargv().  You can then use argv[0] as the
command name instead.

-- 
John Baldwin