Hello, Oleg! On Wed, May 08, 2019 at 05:25:36PM +0200, Oleg Nesterov wrote: > On 05/07, Roman Gushchin wrote: > > > > --- a/kernel/signal.c > > +++ b/kernel/signal.c > > @@ -2484,9 +2484,6 @@ bool get_signal(struct ksignal *ksig) > > sigdelset(¤t->pending.signal, SIGKILL); > > recalc_sigpending(); > > current->jobctl &= ~JOBCTL_TRAP_FREEZE; > > just noticed... perhaps it makes more sense to clear JOBCTL_TRAP_FREEZE > before recalc_sigpending(). Or simply not clear it at all, see below. Agree, we don't need to clear it, because there is no way back for the task at this moment, only exiting. I'm dropping this line. > > > - spin_unlock_irq(&sighand->siglock); > > - if (unlikely(cgroup_task_frozen(current))) > > - cgroup_leave_frozen(true); > > goto fatal; > > } > > > > @@ -2608,8 +2605,10 @@ bool get_signal(struct ksignal *ksig) > > continue; > > } > > > > - spin_unlock_irq(&sighand->siglock); > > fatal: > > + spin_unlock_irq(&sighand->siglock); > > + if (unlikely(cgroup_task_frozen(current))) > > + cgroup_leave_frozen(true); > > Yes, ptrace_signal() can return a fatal signal... and in this case we do not > clear JOBCTL_TRAP_FREEZE. This doesn't look consistent with the code above. The same here. > > > > I can only repeat that somehow we need to cleanup/improve the whole logic. > > Say, a traced task reports syscall-enter. ptrace_stop() does enter_frozen(). > The cgroup can become CGRP_FROZEN after that. Now the debugger does PTRACE_CONT, > the frozen task actually starts the syscall. Obviously not good. > > Heh, and if this syscall is sys_exit or sys_exit_group we can hit the same > warning. Ok, I totally agree, but let's fix this noisy WARN_ON() for now, to have some time to think about the rest. I believe this will fix it for now: https://github.com/rgushchin/linux/commit/3f65507e407c81d3cdf4a9145f36a8d0f755ca04 Please, let me know if you have any concerns here, otherwise I'll ask Tejun to pull it asap. Thank you for looking into it! Roman
