Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-12-01 Thread Oleg Nesterov
On 11/29, Jamie Iles wrote: > > On Tue, Nov 29, 2016 at 03:06:00PM +0100, Oleg Nesterov wrote: > > > > > +static inline void signal_clear_flags(struct signal_struct *sig, > > > + unsigned int flags) > > > +{ > > > + sig->flags &= (~flags | SIGNAL_PROTECTED_MASK); > >

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-12-01 Thread Oleg Nesterov
On 11/29, Jamie Iles wrote: > > On Tue, Nov 29, 2016 at 03:06:00PM +0100, Oleg Nesterov wrote: > > > > > +static inline void signal_clear_flags(struct signal_struct *sig, > > > + unsigned int flags) > > > +{ > > > + sig->flags &= (~flags | SIGNAL_PROTECTED_MASK); > >

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-29 Thread Jamie Iles
Hi Oleg, On Tue, Nov 29, 2016 at 03:06:00PM +0100, Oleg Nesterov wrote: > Jamie, > > I am really sorry for the huge delay. No problem! > On 11/16, Jamie Iles wrote: > > > > Since 00cd5c37af (ptrace: permit ptracing of /sbin/init) we can now > > trace init processes. init is initially

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-29 Thread Jamie Iles
Hi Oleg, On Tue, Nov 29, 2016 at 03:06:00PM +0100, Oleg Nesterov wrote: > Jamie, > > I am really sorry for the huge delay. No problem! > On 11/16, Jamie Iles wrote: > > > > Since 00cd5c37af (ptrace: permit ptracing of /sbin/init) we can now > > trace init processes. init is initially

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-29 Thread Oleg Nesterov
Jamie, I am really sorry for the huge delay. On 11/16, Jamie Iles wrote: > > Since 00cd5c37af (ptrace: permit ptracing of /sbin/init) we can now > trace init processes. init is initially protected with > SIGNAL_UNKILLABLE which will prevent fatal signals such as SIGSTOP, but > there are a

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-29 Thread Oleg Nesterov
Jamie, I am really sorry for the huge delay. On 11/16, Jamie Iles wrote: > > Since 00cd5c37af (ptrace: permit ptracing of /sbin/init) we can now > trace init processes. init is initially protected with > SIGNAL_UNKILLABLE which will prevent fatal signals such as SIGSTOP, but > there are a

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-28 Thread Jamie Iles
Hi Oleg, On Thu, Nov 17, 2016 at 08:04:20PM +0100, Oleg Nesterov wrote: > On 11/16, Jamie Iles wrote: > > > > This can result in init becoming stoppable/killable after tracing. For > > example, running: > > > > while true; do kill -STOP 1; done & > > strace -p 1 > > > and then stopping

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-28 Thread Jamie Iles
Hi Oleg, On Thu, Nov 17, 2016 at 08:04:20PM +0100, Oleg Nesterov wrote: > On 11/16, Jamie Iles wrote: > > > > This can result in init becoming stoppable/killable after tracing. For > > example, running: > > > > while true; do kill -STOP 1; done & > > strace -p 1 > > > and then stopping

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-17 Thread Oleg Nesterov
On 11/16, Jamie Iles wrote: > > This can result in init becoming stoppable/killable after tracing. For > example, running: > > while true; do kill -STOP 1; done & > strace -p 1 > and then stopping strace and the kill loop will result in init being > left in state TASK_STOPPED. Sending

Re: [PATCH] signal: protect SIGNAL_UNKILLABLE from unintentional clearing.

2016-11-17 Thread Oleg Nesterov
On 11/16, Jamie Iles wrote: > > This can result in init becoming stoppable/killable after tracing. For > example, running: > > while true; do kill -STOP 1; done & > strace -p 1 > and then stopping strace and the kill loop will result in init being > left in state TASK_STOPPED. Sending