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(). -- 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
