Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751618AbdFIMqA (ORCPT ); Fri, 9 Jun 2017 08:46:00 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39306 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751534AbdFIMp7 (ORCPT ); Fri, 9 Jun 2017 08:45:59 -0400 Date: Fri, 9 Jun 2017 05:45:54 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Krister Johansen , Ingo Molnar , linux-kernel@vger.kernel.org, Steven Rostedt , Paul Gortmaker , Thomas Gleixner Subject: Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up. Reply-To: paulmck@linux.vnet.ibm.com References: <20170609032546.GF2553@templeofstupid.com> <20170609071957.GJ8337@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170609071957.GJ8337@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17060912-0048-0000-0000-000001A12252 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007200; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00872297; UDB=6.00433991; IPR=6.00652367; BA=6.00005406; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015760; XFM=3.00000015; UTC=2017-06-09 12:45:57 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17060912-0049-0000-0000-0000417415BC Message-Id: <20170609124554.GF3721@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-09_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706090225 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 761 Lines: 15 On Fri, Jun 09, 2017 at 09:19:57AM +0200, Peter Zijlstra wrote: > On Thu, Jun 08, 2017 at 08:25:46PM -0700, Krister Johansen wrote: > > The behavior of swake_up() differs from that of wake_up(), and from the > > swake_up() that came from RT linux. A memory barrier, or some other > > synchronization, is needed prior to a swake_up so that the waiter sees > > the condition set by the waker, and so that the waker does not see an > > empty wait list. > > Urgh.. let me stare at that. But it sounds like the wrong solution since > we wanted to keep the wait and swait APIs as close as possible. But don't they both need some sort of ordering, be it memory barriers or locking, to handle the case where the wait/swait doesn't actually sleep? Thanx, Paul