Re: ptrace warning due to "cgroup: get rid of cgroup_freezer_frozen_exit()"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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(&current->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.

> -               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.



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.

Oleg.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux