Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers

[Oleg Nesterov]

On 12/11, Paul Turner wrote:
>
> 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,

I still don't understand this...

signal_pending_check(current->state) before schedule() should be fine
even if it actually reads current->state twice and it races with wakeup/
signal_wake_up() which can change the caller's state.

> but in the context of the state which we previously
> _entered_ schedule() on.

Yes, but only if we do this after return from schedule().


But somehow this change helps. It adds the subtle difference(s), for example
__wait_on_bit_lock() won't do another test_and_set_bit() if the sleeping
caller is killed, but this shouldn't matter.

And if this does matter because it has a buggy user, then it is not clear why
the change from Vladimir helps too.

The common part is that both changes make "return 1" impossible, but according
to another email from Peter this just makes the fail less likely.

I am really puzzled.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/