From owner-freebsd-arch@freebsd.org Fri Jun 1 13:41:59 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 836B6FD4DD4 for ; Fri, 1 Jun 2018 13:41:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3C67C40B; Fri, 1 Jun 2018 13:41:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTP id w51Dfl4d029181; Fri, 1 Jun 2018 16:41:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w51Dfl4d029181 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w51DflDO029180; Fri, 1 Jun 2018 16:41:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 1 Jun 2018 16:41:47 +0300 From: Konstantin Belousov To: Gleb Popov Cc: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc Message-ID: <20180601134147.GB3789@kib.kiev.ua> References: <20180530001638.GN99063@spindle.one-eyed-alien.net> <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 13:41:59 -0000 On Fri, Jun 01, 2018 at 02:44:34PM +0300, Gleb Popov wrote: > On Wed, May 30, 2018 at 5:10 AM, John Baldwin wrote: > > > > > -- > > 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 > > >> #include > > >> #include > > >> #include > > >> > > >> #include > > >> #include > > >> #include > > >> #include > > >> > > >> 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. > > > > Thanks for your suggestion. I've tried that out and it does seem to work. > However, I'm slightly confused by the fact that procstat_getargv() returns > only command name and not the whole argv line, as function's name suggests. > Here is my code: > > int main(int argc, char* argv[]) > { > kvm_t * kvm = kvm_open(nullptr, "/dev/null", nullptr, O_RDONLY, ""); > > int cnt; > struct kinfo_proc * kp = kvm_getprocs(kvm, KERN_PROC_PID, getpid(), > &cnt); > > struct procstat * ps = procstat_open_sysctl(); > > char ** argv0 = procstat_getargv(ps, kp, 0); > > puts(*argv0); > > procstat_close(ps); > kvm_close(kvm); > > return 0; > } > > Running "veryveryverylongcommandname" correctly produces > "veryveryverylongcommandname" line on stdout, but > "veryveryverylongcommandname args args args" also gives only > "veryveryverylongcommandname". Is this correct behavior or am I missing > something? You do not print argv[1] etc, so they are not printed. Note that availabitily of the argv and env is optional, the data can be missed for many reasons. Kernel is guaranteed to see it only during execve(2), not between. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"