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, 24 Jan 2012 13:54:43 -0800 [thread overview]
Message-ID: <20120124135443.2772d455.akpm@linux-foundation.org> (raw)
In-Reply-To: <1327183785-27023-1-git-send-email-jengelh@medozas.de>
On Sat, 21 Jan 2012 23:09:44 +0100
Jan Engelhardt <jengelh@medozas.de> wrote:
> I found that the kernel BUG()s out, already during boot, when bumping
> TASK_COMM_LEN to a value larger than 16
We can never increase TASK_COMM_LEN - it is part of the kernel ABI/API.
Doing so would destroy existing userspace which uses 16-byte buffers.
> (and I can imagine the same
> problem unfolding as well if it is set to something smaller).
hm, that's a surprise. Decreasing TASK_COMM_LEN is at least slightly
possible but it's hard to see why we should do so.
> Various places do insufficient length checks, simply assume certain
> sizes or hardcode things. Even though e.g. get_task_comm clearly
> documents that its buffer ought to be TASK_COMM_LEN long, I do believe
> that an extra size parameter, such as added in this patch, is a lot
> more robust than relying on callers getting the buffer size right.
>
> With this patch, I no longer experience crashes, but that is not to
> say that there are not any further places (e.g. in modules I never
> use) with flakey ->comm handling.
You do seem to have found a few warts around the task->comm handling.
But I don't believe that addressing them justifies adding new code
(adding another argument to get_task_comm).
If you're interested in working on this stuff I'd suggest that we
confine ourselves to cleaning things up (without adding code) rather
than permitting a different TASK_COMM_LEN. Things like replacing "16"
with TASK_COMM_LEN.
next prev parent reply other threads:[~2012-01-24 21:54 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 ` Andrew Morton [this message]
2012-02-01 1:15 ` [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN != 16 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
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=20120124135443.2772d455.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.