Jiri Slaby wrote: > We currently access current->comm directly. As we have > prctl(PR_SET_NAME), we need the access be protected by task_lock. This > is exactly what get_task_comm does, so use it. Tetsuo Handa wrote: > Andrew Morton wrote: > > PR_SET_NAME uses set_task_comm() which has appropriate locking to > > protect against get_task_comm(). > > > > If kernel code directly accesses task->comm without taking task_lock() > > then yes, it's racy. > > I see. Well, > > grep -r -- '->comm[,;)]' . > > in 2.6.39-rc6 shows so many users directly reading/updating, including > > case 'e': > err = cn_printf(cn, "%s", current->comm); > break; > > in format_corename(). > > > Hopefully John Stultz will soon be presenting us with a %p modifier for > > displaying task_struct.comm. > > That will be nice. But caller might by error call printk() with that modifier > between task_lock() and task_unlock(). > I thought "%p modifier" means add a new modifier to pointer() in lib/vsprintf.c , but this patch is for format_corename(). Do we have a plan to add a new modifier to pointer() in lib/vsprintf.c for safely reading task_struct.comm ? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
