On Wed, Aug 15, 2012 at 10:56 AM, Oleg Nesterov <o...@redhat.com> wrote: > On 08/15, Peter Zijlstra wrote: >> >> On Wed, 2012-08-15 at 15:01 +0200, Oleg Nesterov wrote: >> > BTW, set_task_comm()->wmb() and memset() should die. There are >> > not needed afaics, and the comment is misleading. >> >> As long as we guarantee there's always a terminating '\0', > > Yes, but we already have this guarantee? > > Unless of course some buggy code does something wrong with task->comm[], > but nobody should do this. > > IOW, task->comm[TASK_COMM_LEN - 1] is always 0, no? > >> now strlcpy() >> doesn't pad the result, > > afaics set_task_comm()->strlcpy() doesn't change the last byte too. > >> however if we initialize the ->comm to all 0s in >> fork() > > fork() is special, yes. ->comm is copied by dup_task_struct() and > the new task_struct can have everything in ->comm. But nobody can > see the new task yet, and nobody can play with its ->comm. > > Or I misunderstood? > >> That barrier is indeed completely pointless as there's no pairing >> barrier anywhere. > > Yes, agreed.
It sounds like get_task_comm shouldn't have locking at all then? It should just do a length-limited copy and make sure there is a trailing 0-byte? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
