Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp218422ybl; Mon, 12 Aug 2019 15:00:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqzeIu+EdcOl6Xl2l4EKJeW2moFf7XQS/WbwiFkNfKeQbUd2Faj5zcTUhBCqxhnBHVwK4nWT X-Received: by 2002:a17:90a:d3d4:: with SMTP id d20mr1344972pjw.28.1565647244589; Mon, 12 Aug 2019 15:00:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565647244; cv=none; d=google.com; s=arc-20160816; b=0Wxon3HUedq8CXjY3gwEI2mu6BlMsHjKV6d2dxJuxI/Ux7nm0kgGxZ9UdWlh71T8zT 2fuONi6P+wXYc5MOUHRn9NIqTK8vhDvofoMHD1yREEd8J34jandG3cgNogbXj250QVmL Nf0p13WlpkpVwPTbycjFHwjGFXoQZnznc2v4i7TFlD4CN4YbrqwDf+NdcJh6GREtbPNZ ISIL2bDi/WRIIzKIw8MGQjobc9hBlUWYV+NLTc9U4NS91HHjBc0LHL2oQFMdNLD98GQK 9xBCnCdpJEk/oUBwIJ/kUshZhDPi9Pup3XY+10yLbvnxeLIJsMz9naA0KJBfPKVpAhJZ qKbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=YqkGlmHfP8JzMqI3XTqf/HMskihJouhxQs3ne3m9B94=; b=g93kUc23xKp05ViZPB7EEr923Yv+M8/wZmgok3y0ifc/tpSDqDtDvvsqUS59ZXCzg4 BaRHICS+0emfMDCWGaV2JVduWPfsLmUmOKYQup26cOvpbh6a9VxgIV9RHqfOTJtj7zJ+ 0bT2+DNvStxhoXjpXAbYkmacwmbwAcu8cDoIdjQaQbxn+6Kr6IdiuE1Kgy8G/XdGy+6Y Q06ejEqNR8ItQD7J3x0JBCSW1jntv6JcQb38SPsC1CpEXicCsihKJD7DFdSKopOu0t/d U74f6DtSpXbJLlhFMsvSWAvXRuPNDtfL5n3HFnnbUwqYd4GfvZdi+TnROAIQnO8GulAd zj2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d9si64298269pgv.577.2019.08.12.15.00.28; Mon, 12 Aug 2019 15:00:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727562AbfHLUXO (ORCPT + 99 others); Mon, 12 Aug 2019 16:23:14 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47728 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726925AbfHLUXO (ORCPT ); Mon, 12 Aug 2019 16:23:14 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7CKLhwS016225; Mon, 12 Aug 2019 16:22:40 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ubd81c51f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Aug 2019 16:22:40 -0400 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x7CKMdDQ019426; Mon, 12 Aug 2019 16:22:39 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ubd81c50y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Aug 2019 16:22:39 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x7CK5F8J030208; Mon, 12 Aug 2019 20:22:38 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma02dal.us.ibm.com with ESMTP id 2u9nj62kr3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Aug 2019 20:22:38 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x7CKMbni53281230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Aug 2019 20:22:37 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B9D7BB2066; Mon, 12 Aug 2019 20:22:37 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C846B205F; Mon, 12 Aug 2019 20:22:37 +0000 (GMT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.154]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 12 Aug 2019 20:22:37 +0000 (GMT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 9371916C9A7D; Mon, 12 Aug 2019 13:22:41 -0700 (PDT) Date: Mon, 12 Aug 2019 13:22:41 -0700 From: "Paul E. McKenney" To: "Joel Fernandes (Google)" Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Jonathan Corbet , Josh Triplett , Lai Jiangshan , linux-doc@vger.kernel.org, Mathieu Desnoyers , "Rafael J. Wysocki" , rcu@vger.kernel.org, Steven Rostedt , Tejun Heo Subject: Re: [PATCH 2/3] doc: Update documentation about list_for_each_entry_rcu (v1) Message-ID: <20190812202241.GP28441@linux.ibm.com> Reply-To: paulmck@linux.ibm.com References: <20190811221111.99401-1-joel@joelfernandes.org> <20190811221111.99401-2-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190811221111.99401-2-joel@joelfernandes.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-12_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908120202 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 11, 2019 at 06:11:10PM -0400, Joel Fernandes (Google) wrote: > This patch updates the documentation with information about > usage of lockdep with list_for_each_entry_rcu(). > > Signed-off-by: Joel Fernandes (Google) Thank you!!! I queued this for v5.5 with the following wordsmithing. Please check to make sure that I didn't mess anything up. Thanx, Paul ------------------------------------------------------------------------ commit d06933df6b5919abfd298291f2a6b0a3a095ae64 Author: Joel Fernandes (Google) Date: Sun Aug 11 18:11:10 2019 -0400 doc: Update list_for_each_entry_rcu() documentation This commit updates the documentation with information about usage of lockdep with list_for_each_entry_rcu(). Signed-off-by: Joel Fernandes (Google) [ paulmck: Wordsmithing. ] Signed-off-by: Paul E. McKenney diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt index da51d3068850..89db949eeca0 100644 --- a/Documentation/RCU/lockdep.txt +++ b/Documentation/RCU/lockdep.txt @@ -96,7 +96,17 @@ other flavors of rcu_dereference(). On the other hand, it is illegal to use rcu_dereference_protected() if either the RCU-protected pointer or the RCU-protected data that it points to can change concurrently. -There are currently only "universal" versions of the rcu_assign_pointer() -and RCU list-/tree-traversal primitives, which do not (yet) check for -being in an RCU read-side critical section. In the future, separate -versions of these primitives might be created. +Like rcu_dereference(), when lockdep is enabled, RCU list and hlist +traversal primitives check for being called from within an RCU read-side +critical section. However, a lockdep expression can be passed to them +as a additional optional argument. With this lockdep expression, these +traversal primitives will complain only if the lockdep expression is +false and they are called from outside any RCU read-side critical section. + +For example, the workqueue for_each_pwq() macro is intended to be used +either within an RCU read-side critical section or with wq->mutex held. +It is thus implemented as follows: + + #define for_each_pwq(pwq, wq) + list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node, + lock_is_held(&(wq->mutex).dep_map)) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 17f48319ee16..58ba05c4d97f 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -290,7 +290,7 @@ rcu_dereference() at any time, including immediately after the rcu_dereference(). And, again like rcu_assign_pointer(), rcu_dereference() is typically used indirectly, via the _rcu list-manipulation - primitives, such as list_for_each_entry_rcu(). + primitives, such as list_for_each_entry_rcu() [2]. [1] The variant rcu_dereference_protected() can be used outside of an RCU read-side critical section as long as the usage is @@ -305,6 +305,14 @@ rcu_dereference() a lockdep splat is emitted. See Documentation/RCU/Design/Requirements/Requirements.rst and the API's code comments for more details and example usage. + [2] If the list_for_each_entry_rcu() instance might be used by + update-side code as well as by RCU readers, then an additional + lockdep expression can be added to its list of arguments. + For example, given an additional "lock_is_held(&mylock)" argument, + the RCU lockdep code would complain only if this instance was + invoked outside of an RCU read-side critical section and without + the protection of mylock. + The following diagram shows how each API communicates among the reader, updater, and reclaimer.