On 10/28, Roland McGrath wrote: > > Unlike the old code that freaked upstream reviewers all the way out, > this has very simple lifetime rules for struct utrace. Once allocated, > it lives until task_struct is freed. The utrace_task_alloc() logic > covers the only race (at first attach), and that seems pretty easy > to understand and be confident in.
Yep, I already noticed utrace-indirect branch before. While I didn't look at the code closely, this change looks very simple and imho desirable. I'll try to read it carefully later. > I am a bit concerned about letting the ugly utrace_struct.h way ever get > merged in, so that to fix it later we have to convince people all over > again about "changing what works". But of course I am really not at all > sure whether even this innocuous version will upset the reviewers. Yes, this is the question ;) My opinion, it would be better to send this as a separate patch, when the utrace is already merged. Because they were too many complaints about task_struct->utrace pointer before. And given that nobody actually read the code during review (at least this happened before), I am afraid we can have "ugh, it is a pointer again?" complaints. But of course I don't really sure. Speaking of this change. Do you think we can remove "void *cookie" from exit_notify() pathes before sending utrace/ptrace to lkml? Afaics, given that task->utrace never goes away utrace-indirect doesn't need this hack. Oleg.
