From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751901AbbIHAXI (ORCPT ); Mon, 7 Sep 2015 20:23:08 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:35327 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbbIHAXE (ORCPT ); Mon, 7 Sep 2015 20:23:04 -0400 Date: Tue, 8 Sep 2015 08:22:45 +0800 From: Boqun Feng To: Oleg Nesterov Cc: "Paul E. McKenney" , Michal Hocko , Peter Zijlstra , LKML , David Howells , Linus Torvalds , Jonathan Corbet Subject: Re: wake_up_process implied memory barrier clarification Message-ID: <20150908002245.GA16157@fixme-laptop.cn.ibm.com> References: <20150829142707.GA19263@redhat.com> <20150831003719.GC924@fixme-laptop.cn.ibm.com> <20150831183335.GA26333@redhat.com> <20150831203739.GX4029@linux.vnet.ibm.com> <20150901034014.GD1071@fixme-laptop.cn.ibm.com> <20150901095923.GB31368@redhat.com> <20150901145024.GA8007@fixme-laptop.cn.ibm.com> <20150901163923.GA20055@redhat.com> <20150902011027.GB8007@fixme-laptop.cn.ibm.com> <20150907170652.GA32459@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20150907170652.GA32459@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Oleg, On Mon, Sep 07, 2015 at 07:06:52PM +0200, Oleg Nesterov wrote: > Sorry for delay, >=20 > On 09/02, Boqun Feng wrote: > > > > On Tue, Sep 01, 2015 at 06:39:23PM +0200, Oleg Nesterov wrote: > > > On 09/01, Boqun Feng wrote: > > > > > > > > On Tue, Sep 01, 2015 at 11:59:23AM +0200, Oleg Nesterov wrote: > > > > > > > > > > And just in case, wake_up() differs in a sense that it doesn't ev= en need > > > > > that STORE-LOAD barrier in try_to_wake_up(), we can rely on > > > > > wait_queue_head_t->lock. Assuming that wake_up() pairs with the "= normal" > > > > > wait_event()-like code. > > > > > > Looks like, you have missed this part of my previous email. See below. > > > > I guess I need to think through this, though I haven't found any problem > > in wake_up() if we remove the STORE-LOAD barrier in try_to_wake_up(). > > And I know that in wake_up(), try_to_wake_up() will be called with > > holding wait_queue_head_t->lock, however, only part of wait_event() > > holds the same lock, I can't figure out why the barrier is not needed > > because of the lock.. >=20 > This is very simple. __wait_event() does >=20 > for (;;) { > prepare_to_wait_event(WQ, ...); // takes WQ->lock >=20 > if (CONDITION) > break; >=20 > schedule(); > } >=20 > and we have >=20 > CONDITION =3D 1; > wake_up(WQ); // takes WQ->lock >=20 > on another side. >=20 > Suppose that __wait_event() wins and takes WQ->lock first. It can block > then. In this case wake_up() must see the result of set_current_state() > and list_add() when it takes the same lock, otherwise spin_lock() would > be simply buggy. So it will wake the waiter up. >=20 > At the same time, if __wait_event() takes this lock after wake_up(), it > can not miss CONDITION =3D 1. It must see it after it takes the lock, and > of course after it drops the lock too. >=20 Yes, you're right! I wasn't aware that in prepare_to_wait_event(), set_current_state() is called with the WQ->lock. > So I am not sure I understand your concerns in this case... >=20 It's my mistake. Thank you for your explanation ;-) Regards, Boqun --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV7ipRAAoJEEl56MO1B/q4G3UH/jo8rSHwQQBiXfhzXyi/EsIL bL+iRhxueOs1CuuEVKU1GikEMHWMizX/Jws2Vw17zBCozLsLsFcvrWnwMeolPLmH 2uYCAW+Do/ZEwbsHT+Jj08D4NH1D2KuTAZ4vuavy5xQ9Y6PSK0HqvZ1maDu0RSH5 xGzogbTTxV3k/Toz2HnwFWRjHEUk5+OqE/nmAUtoPIMiRUqHgQQyyoNXNgskNxrP HJDm43XX8xUyv6cpmmXuTvUdjdMlLtkKgx+L7mVXBNhmVNomfdGemrPaj5z6bI5J smcwO8QKYKo/jzXrhCi0u8xXBoqg7moHzdOcrYJhpBahE48dZ0jRn/7FAOauDSs= =msAz -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+--