From: J Freyensee <james_p_freyensee@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org, suhail.ahmed@intel.com,
christophe.guerard@intel.com
Subject: Re: [PATCH 3/4] Intel PTI implementaiton of MIPI 1149.7.
Date: Fri, 22 Apr 2011 10:57:14 -0700 [thread overview]
Message-ID: <1303495034.13457.121.camel@localhost> (raw)
In-Reply-To: <alpine.DEB.2.00.1104191822440.8047@chino.kir.corp.google.com>
On Tue, 2011-04-19 at 18:25 -0700, David Rientjes wrote:
> On Tue, 19 Apr 2011, james_p_freyensee@linux.intel.com wrote:
>
> > +static void pti_control_frame_built_and_sent(struct pti_masterchannel *mc)
> > +{
> > + struct pti_masterchannel mccontrol = {.master = CONTROL_ID,
> > + .channel = 0};
> > + const char *control_format = "%3d %3d %s";
> > +
> > + char comm[sizeof(current->comm) + 1];
> > + u8 control_frame[CONTROL_FRAME_LEN];
> > +
> > + if (!in_interrupt())
> > + get_task_comm(comm, current);
> > + else
> > + strcpy(comm, "Interrupt");
> > +
> > + /* Ensure our buffer is zero terminated */
> > + comm[sizeof(current->comm)] = 0;
> > +
>
> You definitely need to use get_task_comm() here, but that means you can't
> allocate char comm[] on the stack with anything but TASK_COMM_LEN, which
> is small enough that it shouldn't be an issue. Otherwise there's nothing
> protecting sizeof(current->comm) from changing without holding
> task_lock(current).
I'm going to look at utilizing get_task_comm() more in this function,
but I think I am okay even if I miss one, as I am just doing a read from
it. What is written in set_task_comm() states that threads may read
from current->comm without holding the task_lock(). The name could be
incomplete, which would be non-ideal (but acceptable), but it's supposed
to be safe from non-terminating string reads.
And it seems like the fix for
> + comm[sizeof(current->comm)] = 0;
can just be comm[TASK_COMM_LEN].
next prev parent reply other threads:[~2011-04-22 17:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 22:58 [PATCH 3/4] Intel PTI implementaiton of MIPI 1149.7 james_p_freyensee
2011-04-19 23:15 ` Randy Dunlap
2011-04-20 23:05 ` J Freyensee
2011-04-20 23:10 ` Randy Dunlap
2011-04-21 21:06 ` J Freyensee
2011-04-21 21:17 ` Randy Dunlap
2011-04-20 1:25 ` David Rientjes
2011-04-20 9:46 ` Alan Cox
2011-04-20 18:07 ` J Freyensee
2011-04-22 17:57 ` J Freyensee [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-04-22 23:32 james_p_freyensee
2011-04-24 0:55 ` Jesper Juhl
2011-04-24 1:08 ` Jesper Juhl
2011-05-05 17:06 ` J Freyensee
2011-05-05 20:37 ` Jesper Juhl
2011-05-05 17:27 ` J Freyensee
2011-05-05 20:42 ` Jesper Juhl
2011-05-05 22:30 ` J Freyensee
2011-05-06 23:56 james_p_freyensee
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=1303495034.13457.121.camel@localhost \
--to=james_p_freyensee@linux.intel.com \
--cc=christophe.guerard@intel.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=suhail.ahmed@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox