Messages in this thread | | | Date | Fri, 11 Dec 2015 12:39:59 +0100 | From | Peter Zijlstra <> | Subject | Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers |
| |
On Fri, Dec 11, 2015 at 03:30:33AM -0800, Paul Turner wrote:
> > Blergh, all I've managed to far is to confuse myself further. Even > > something like the original (+- the EINTR) should work when we consider > > the looping, even when mixed with an occasional spurious wakeup. > > > > > > int bit_wait() > > { > > if (signal_pending_state(current->state, current)) > > return -EINTR; > > schedule(); > > }
So I asked Vladimir to test that (simply changing the return from 1 to -EINTR) and it made his fail much less likely but it still failed in the same way.
So I'm fairly sure I'm still missing something :/
> Hugh asked me about this after seeing a crash, here's another exciting > way in which the current code breaks -- this one actually quite > serious:
Yep, this got reported by Jan and I did kick myself for that.
> Peter's proposed follow-up above looks strictly more correct. We need > to evaluate the potential existence of a signal, *after* we return > from schedule, but in the context of the state which we previously > _entered_ schedule() on. > > Reviewed-by: Paul Turner <pjt@google.com>
Right, its maybe a bit overkill, but at this point I'm a tad conservative/paranoid.
Vladimir, Jan could you both please that patch?
lkml.kernel.org/r/20151208104712.GJ6356@twins.programming.kicks-ass.net
Thanks!
| |