Messages in this thread | | | Date | Tue, 31 Jan 2012 19:01:09 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16 |
| |
On Wed, 1 Feb 2012 03:15:50 +0100 (CET) Jan Engelhardt <jengelh@medozas.de> wrote:
> > On Wednesday 2012-02-01 02:49, Andrew Morton wrote: > >> > >> Did my patch not change the existing code sites using ->comm > >> to always copy at most min(userbufsize aka 16, sizeof(t->comm)) bytes, > >> thereby keeping the promise to userspace while at the same time > >> making TASK_COMM_LEN's value freely choosable? > > > >That change is pretty pointless as long as we don't provide APIs to let > >userspace access the expanded size. And I've explained why we cannot > >alter the existing APIs. > > Ah yes, indeed. My reason for augmenting the size of t->comm was so > that `ps afx` could show a more complete name of certain kernel > threads' names. In this case, the kernel delivers the name via > procfs via seq_printf("%s, t->comm),
Where does procfs do this?
> as do a few debug statements > in the fashion of pr_debug("%s/%u ate my CPU", t->comm, t->pid). > So maybe it was not /completely/ pointless.
I agree that the 16-char thing is irritatingly small. But if we were to increase it and to then utilise that increase, those userspace apps which are still using the legacy prctl(PR_GET_NAME) would produce pretty bad output. Instead of "migration/0" and "migration/1" you'd get "migration_threa" and "migration_threa". And "flush-8:32" would maddeningly become "flusher_thread-".
I suppose that would help motivate people to update their tools ;)
| |