Oleg Nesterov <[email protected]> writes: > On 07/26, Eric W. Biederman wrote: >> >> Are the earlier patches looking ok to you? > > I obviously like 1-15. > > "[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING" > is "interesting". I mean it is fine, but at the end of this series it doesn't > matter what we check first, PIDNS_ADDING or fatal_signal_pending() - restart > is not possible in both cases. > > > As for 17-20... Yes I am biased. But I still think the simple approach I tried > to propose from the very beginning is better. At least simpler, in that you do > not need to worry about all these special cases/reasons for signal_pending().
I think worrying about them all now results in a future where we don't have to worry about reasons why we can't let fork continue. Giving a better progress guarantee. Which ultimately should be more maintainable going forward. > And you can not imagine how much I hate "[PATCH 19/20] fork: Have new threads > join on-going signal group stops" ;) Because I spent HOURS looking at this > trivial > patch and I am still not sure... > > To clarify, the CLONE_THREAD with JOBCTL_STOP_PENDING case is simple, I am > mostly > worried about JOBCTL_TRAP_STOP/etc with or without CLONE_THREAD, this adds > some > subtle changes but unfortunately I failed to find something wrong so I > can't argue I can understand taking a hard look at JOBCTL_TRAP_STOP especially as it gets mixed in with the multi-task (whole process) stop handling when at least one of the tasks of a process are being ptraced. To make certain I understood your concern I took a second look at it myself. The ptrace actions are defined to only affect a single task, and except for multi-task stop handling all of the jobctl bits are used for ptrace actions. So I don't see how there is anything we could possibly miss in the jobctl bits. Eric
