lkml.org 
[lkml]   [2014]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Change task_struct->comm to use RCU.
On Tue, Feb 25, 2014 at 09:54:01PM +0900, Tetsuo Handa wrote:
> Lai Jiangshan wrote:
> > CC scheduler people.
> >
> > I can't figure out what we get with this patch.
> >
> OK. Welcome to this thread. I'll explain you what is going on.
>
> Current problem:
>
> printk("%s\n", task->comm) is racy because "%s" format specifier assumes that
> the corresponding argument does not change between strnlen() and the for loop
> at string() in lib/vsnprintf.c . If task->comm was "Hello Linux" until
> strnlen() and becomes "Penguin" before the for loop, "%s" will emit
> "Penguin\0nux" (note the unexpected '\0' byte and the garbage bytes).

I would have actually expected it to stop emitting chars at \0. But
sure. Couldn't care less though; that's what you get, we all know this,
we've all been through this discussion several times. Get over it
already.

One of the last threads on this is:

https://lkml.org/lkml/2011/5/17/516

> Likewise, audit_log_untrustedstring(ab, current->comm) is racy.
> If task->comm was "Hello Linux" until audit_string_contains_control() in
> audit_log_n_untrustedstring() returns false, and becomes "Penguin" before
> memcpy() in audit_log_n_string() is called, memcpy() will emit "Penguin\0nux"
> into the audit log, which results in loss of information (e.g. SELinux
> context) due to the unexpected '\0' byte.

I expect the audit people don't like this? Also, how do audit and the
LSM crap things interact? I thought they were both different piles of
ignorable goo?

See there's not actually a problem statement here at all, so you can't
go about proposing solutions quite yet.

> Proposed solution:
>
> To fix abovementioned problem, I proposed commcpy() and "%pT" format
> specifier which does
>
> char tmp[16];
> memcpy(tmp, task->comm, 16);
> tmp[15] = '\0';
> sprintf(buf, "%s", tmp);
>
> instead of
>
> sprintf(buf, "%s", task->comm);
>
> .

How about you do what you're supposed to do when you want a reliable
->comm and use get_task_comm()?


\
 
 \ /
  Last update: 2014-02-26 08:41    [W:0.146 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site