Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753044AbbLIVaX (ORCPT ); Wed, 9 Dec 2015 16:30:23 -0500 Received: from victor.provo.novell.com ([137.65.250.26]:33209 "EHLO prv3-mh.provo.novell.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751261AbbLIVaW (ORCPT ); Wed, 9 Dec 2015 16:30:22 -0500 From: NeilBrown To: Peter Zijlstra Date: Thu, 10 Dec 2015 08:30:01 +1100 Cc: torvalds@linux-foundation.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, efault@gmx.de, mingo@kernel.org, hpa@zytor.com, vladimir.murzin@arm.com, linux-tip-commits@vger.kernel.org, jstancek@redhat.com, Oleg Nesterov Subject: Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers In-Reply-To: <20151209074033.GF6357@twins.programming.kicks-ass.net> References: <20151201130404.GL3816@twins.programming.kicks-ass.net> <20151208104712.GJ6356@twins.programming.kicks-ass.net> <87zixkph0m.fsf@notabene.neil.brown.name> <20151209074033.GF6357@twins.programming.kicks-ass.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu) Message-ID: <87si3bpaxy.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2273 Lines: 63 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, Dec 09 2015, Peter Zijlstra wrote: > On Wed, Dec 09, 2015 at 12:06:33PM +1100, NeilBrown wrote: >> On Tue, Dec 08 2015, Peter Zijlstra wrote: >>=20 >> >>=20=20 >> > >> > *sigh*, so that patch was broken.. the below might fix it, but please >> > someone look at it, I seem to have a less than stellar track record >> > here... >>=20 >> This new change seems to be more intrusive than should be needed. >> Can't we just do: >>=20 >>=20 >> __sched int bit_wait(struct wait_bit_key *word) >> { >> + long state =3D current->state; > > No, current->state can already be changed by this time. Does that matter? It can only have changed to TASK_RUNNING - right? In that case signal_pending_state() will return 0 and the bit_wait() acts as though the thread was woken up normally (which it was) rather than by a signal (which maybe it was too, but maybe that happened just a tiny bit later). As long as signal delivery doesn't change ->state, we should be safe. We should even be safe testing ->state *after* the call the schedule(). NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWaJ1ZAAoJEDnsnt1WYoG5eR8QAJvNvcYmS8cXimKokBhWctZt +fw45XBSPJX/MLGUA0poC7mTsp46fZXb+aiFyxoY6b3VtVujA+xqvJvjtaYRCs1P 30x8/UbxWPbbKeesdKxhDHT2w+ILVr7z0enK7TMuPWxK0ScwQFVOnqoZQSnypeZE MMEFHQ8vTTaPwvir+jdt0WJcbN2QI5B7W4nDCi4hbRrCH1qEwucmlPz0ds7i6uS2 ulToTzAclYXztaOWTCKN3iTmGmWqui4K3NW+8X0tCUab6DQ+XqicogUVgzTqllGF OA5Rw2efoun3Z9Udx5joTNaQg8KHZ0ujJOQ64uUA3dDJ2RqEgMLlSoWOFOHUo8wS oiQFVkjAUl77XJjh16lojRJDVYQoWT32XM7tV8lPUV9pVVHh+A/0pjI3n3V5PiDh hqavLw1URfoPJGFKMcWThkgREHmWUUyIIfNhQfnbIKy5uoW7UKEg7WronZ/K5IV/ ktQfukHRpj54dEUJmvKILroEWBInwHD3hpgghGry1Wkn8ykOzrMcDF8/NURHWMHh LV/+4YttJ5frfK5DgddiSxe1iNYSkW+dWv/BntvVv0NgK0Z9MrRlIkFwK1XuxTmC VohK8b1kEzmwkullD63d+5XtKnGFLQPgd5pXphI6WMuhiM7h71TOxxIghBQP16Lt 6qy4nUtjO6hygXDnz3Lx =Qraj -----END PGP SIGNATURE----- --=-=-=-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/