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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151215190132.GB19007@redhat.com>
Date:	Tue, 15 Dec 2015 20:01:32 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Paul Turner <pjt@...gle.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	NeilBrown <nfbrown@...ell.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...nel.org>,
	Peter Anvin <hpa@...or.com>, vladimir.murzin@....com,
	linux-tip-commits@...r.kernel.org, jstancek@...hat.com
Subject: Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait
	helpers

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/