> Yes, this is the question ;) At this point I have an irrational distaste for utrace_struct.h and a pathological displeasure at having a contentious upstream discussion on this again. We need to get the "right" code in upstream, and in the "right" state before another lifetime passes. I'm leaving it entirely in your discretion how best to make that happen. My ruminations are just there for whatever they're worth.
> 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. My inclination is that we not fiddle with any tracehook or other changes that do not have a direct positive effect on keeping the utrace code simpler today. If upstream wants us to fiddle with them, then we will. Otherwise we can get things merged, do more rounds of internal changes, and let the dust settle, before we look for cosmetic cleanups. IMHO today it's just more trivia to read over and get distracted by, more fiddling for anyone trying a backport to an older base kernel, etc. I don't really recall the exact details in previous generations of code that made it important to save that pointer across that locking window. Now that you have cleaned up and fixed the attach vs release_task interactions, introduced utrace_finish_jctl, etc., I suspect we could (later) introduce free-on-last-detach behavior and have the code be far easier to follow and more reliable than the past situation. Even then, chances are it wouldn't wind up needing that pointer. But, who knows? It's a trivium compiled away from the tracehook inlines today. Thanks, Roland
