Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Eric W. Biederman
Oleg Nesterov writes: > On 02/12, Eric W. Biederman wrote: >> >> > Here I was trying for the simple minimal change and I hit this landmine. >> > Which leaves me with the question of what should be semantics of signal >> > handling after exit. > > Yes, currently it is undefined. Even signal_pendin

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Oleg Nesterov
On 02/12, Eric W. Biederman wrote: > > > Here I was trying for the simple minimal change and I hit this landmine. > > Which leaves me with the question of what should be semantics of signal > > handling after exit. Yes, currently it is undefined. Even signal_pending() is random. > > I think from

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-12 Thread Eric W. Biederman
ebied...@xmission.com (Eric W. Biederman) writes: > Oleg Nesterov writes: > >> sorry again for delay... >> >> On 02/07, Eric W. Biederman wrote: >>> >>> --- a/kernel/signal.c >>> +++ b/kernel/signal.c >>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig) >>> goto relock; >>

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-11 Thread Eric W. Biederman
Oleg Nesterov writes: > sorry again for delay... > > On 02/07, Eric W. Biederman wrote: >> >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig) >> goto relock; >> } >> >> +/* Has this task already been marked for

Re: [PATCH 1/2] signal: Always notice exiting tasks

2019-02-11 Thread Oleg Nesterov
sorry again for delay... On 02/07, Eric W. Biederman wrote: > > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig) > goto relock; > } > > + /* Has this task already been marked for death? */ > + ksig->info.si_s

[PATCH 1/2] signal: Always notice exiting tasks

2019-02-06 Thread Eric W. Biederman
Recently syzkaller was able to create unkillablle processes by creating a timer that is delivered as a thread local signal on SIGHUP, and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop failing to deliver SIGHUP but always trying. Upon examination it turns out part of the problem is ac