> Ah. I forgot signals-tracehook_notify_jctl-change.patch is still pending in > -mm.
Perhaps we should just rejigger all these together into one new patch (or two, whatever) before akpm submits any of them. > Or you can just merge these 2 patches, perhaps this would be better. As long as we have akpm drop/update the any conflicting ones, sure. > > The signal.c change should go upstream ASAP, and that patch should also > > include a change to the tracehook_notify_jctl kerneldoc so that it is > > accurate about the locking et al. > > Confused, signals-tracehook_notify_jctl-change.patch already updated the > comment? I was looking at the Linus tree, not the -mm tree (I always do). If that prerequisite patch (or merged rejiggered patch or whatever) updates the comments that is fine. I was also just noticing the other callers of tracehook_notify_jctl, which should all be rejiggered as makes most sense for the locking change (maybe that pending patch already did that). > > This warrants a comment here about the first if. The only reason it is > > there is that tracehook_notify_jctl is allowed to drop and reacquire the > > siglock, > > and SIGCONT may come in between, Right, or the various other things (SIGKILL, etc.). Thanks, Roland