From: Andrew Morton <akpm@linux-foundation.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16
Date: Tue, 31 Jan 2012 19:01:09 -0800 [thread overview]
Message-ID: <20120131190109.b53347fd.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.LNX.2.01.1202010257240.29848@frira.zrqbmnf.qr>
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 ;)
next prev parent reply other threads:[~2012-02-01 3:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-21 22:09 [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16 Jan Engelhardt
2012-01-21 22:09 ` [PATCH 2/2] treewide: avoid truncation of process name Jan Engelhardt
2012-01-24 21:54 ` [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16 Andrew Morton
2012-02-01 1:15 ` Jan Engelhardt
2012-02-01 1:23 ` Andrew Morton
2012-02-01 1:35 ` Jan Engelhardt
2012-02-01 1:49 ` Andrew Morton
2012-02-01 2:15 ` Jan Engelhardt
2012-02-01 3:01 ` Andrew Morton [this message]
2012-02-22 12:48 ` Jan Engelhardt
2012-02-22 20:58 ` Andrew Morton
2012-02-23 9:09 ` Jan Engelhardt
2012-02-23 9:57 ` Andrew Morton
2012-02-23 11:19 ` Jan Engelhardt
2012-02-23 17:30 ` Andrew Morton
2012-02-23 21:59 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120131190109.b53347fd.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jengelh@medozas.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.