From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C19072DAFAF for ; Mon, 29 Jun 2026 05:21:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782710486; cv=none; b=uzEKXntaOZMO8LcIBh0UrXKdELdv3X2ZUQoIsoRt4hX5+DayVZUi+Ihe8wbVOzEbkYn3Y2EJ3fQ+k/dBpPgIR2KunLFtilaOCFzAfkdtyHE+w/F9QU+AsbCBeKBu6f80wHfvesGE27F2UAYvhRxLyvTfGNIZ/GPYUcPJZ6hs7YU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782710486; c=relaxed/simple; bh=ZoWTuvPIDkRwyDxrDbCqnQ+HnjD6yHtDOkZnlQxDha4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LF84nIshpOfeiWY4sKSaaIJ2/UkpJ3M0xghV0U/vYzOfuFrB0MALqD4LymAleNl4xR2hdkRbk/IdHDv1x1kGkQllr5XvKlriiM7F9xo8Tm8X6hgfd96z44hLY+PCtbq755yK7Qljd1ZO3ehclUqmdQ8q79kwKCqXhb83HxhDoXs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=j8da8krH; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="j8da8krH" Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65T3IXYT2253242; Mon, 29 Jun 2026 05:20:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=FTskOd 2KI375AZ9yqcplRwIqxer87SS/svGqw+l5Zg8=; b=j8da8krHgaV9qr+q92pa2L UE+h7ASAbbPcjM5gdJy0khj2iKSnp8bTiYXwj0R5iUIty8kzTY7BGBu9Adu31U6H 9oRGRLiQd4y9pk4ywtJ1MfQMXYwaz3On5RV9D4CZ6BE93RhYF0BeexkNfXtaFjv7 QsmZqN8K7hqfwBDLtIGyTE5t2SSYLb5aqHd+ia0mDKAZL6gIA0K4RgoS3RSp6vJP +TykBphmLYbR6ZaanYHUWKxVg1QLPBmssJN4YQ9+UURidk3H/e7kUSPOgQaiBO6H ZxTRoMy+Xh8x2qgQXW4kqP/QptIFSrsElzfesbJw6RadH34wsiFFYQ5bykYzlpVw == Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4f26qfqjtd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2026 05:20:45 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 65T5JelK032435; Mon, 29 Jun 2026 05:20:44 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([172.16.1.70]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4f2s7vv2wg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2026 05:20:44 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (smtpav05.wdc07v.mail.ibm.com [10.39.53.232]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 65T5KB4L25494176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Jun 2026 05:20:11 GMT Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2784258043; Mon, 29 Jun 2026 05:20:44 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BB72758061; Mon, 29 Jun 2026 05:20:40 +0000 (GMT) Received: from [9.123.7.57] (unknown [9.123.7.57]) by smtpav05.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 29 Jun 2026 05:20:40 +0000 (GMT) Message-ID: <2a3c6a56-a9a6-461e-80ca-c0f2b4203bff@linux.ibm.com> Date: Mon, 29 Jun 2026 10:50:39 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2 05/17] nvme: add Clang context annotations for nvme_ns_head::current_path To: paulmck@kernel.org, Marco Elver Cc: Christoph Hellwig , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com, bvanassche@acm.org, gjoyce@linux.ibm.com References: <20260614131541.2017845-1-nilay@linux.ibm.com> <20260614131541.2017845-6-nilay@linux.ibm.com> <20260626064050.GE10731@lst.de> <41a4cb5a-077c-499f-b060-2a4263303350@paulmck-laptop> <62bbec8e-6eb5-4024-acba-6be1e7f33080@paulmck-laptop> Content-Language: en-US From: Nilay Shroff In-Reply-To: <62bbec8e-6eb5-4024-acba-6be1e7f33080@paulmck-laptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=RYqgzVtv c=1 sm=1 tr=0 ts=6a4200ae cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=VwQbUJbxAAAA:8 a=1XWaLZrsAAAA:8 a=VnNF1IyMAAAA:8 a=w9sESrHmrRdCZCX2hioA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwNjI5MDA0MyBTYWx0ZWRfXw8gCqkjPQPdx dyQScPIH3f3mgenr6tf1+rmCbZ+tFNHQnTKJV+HExePXs3AuU+HSoRiPcac9+E/w6EV+pYg4jPf mt4xyJMSXy665pfW+9lGQaH9Brsul0I= X-Proofpoint-GUID: wHdL9Ay8uNuZD3YyxUI7BqsrETtdRHys X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjI5MDA0MyBTYWx0ZWRfXyZl3ZINnQcK9 +o23c3wLLv2j8m1kmGfCZ55dy6TBLaHcYQbCMHxd/uP4gkmN3kJlDmzFJr6mhJ7wN4QLM5GOcrq v8q1xRsA8h1282a4D7yTEmRcXVJdyQGJxsGWTt1EkZHMUZdTOZPbS8xfi5UJ3gRN7+ah2ilm465 BLEWKCdp1Fvhbi7Hb6aA7VwIk3zlKe3Y0RZUGOatQ02d9JMhSwYsMRYeirEZQGb1Xb9SYl+oDH3 41eHr40wx3I72/ky6Jzxrv8m8Q3v1B9PPNK4cNNGfpbZn3K1K4+mdeMjPko7KcrtbzFnlmIkXFP SgM3XWzAe27J6goGjuIe+zZM2WIVtggFld3r96tt08QbjbEPjY7OPAsMMfEL7CCODlVyndH/6o1 urDgS0xQ9A5kM4tbX0NRL8s1CAbyFXqTHDS1uwa/A2F+Lk0/J+iX9x8uTYxgMg6UwSth22RSQzg 2vghFo96snzdHwtKbtA== X-Proofpoint-ORIG-GUID: JiecEmH_B_fT_8RSJonngP8O0XlhjB5G X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-29_01,2026-06-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2606290043 On 6/28/26 9:37 PM, Paul E. McKenney wrote: > On Sun, Jun 28, 2026 at 08:00:00AM +0200, Marco Elver wrote: >> On Sat, 27 Jun 2026 at 19:14, Paul E. McKenney wrote: >>> >>> On Sat, Jun 27, 2026 at 05:38:44PM +0200, Marco Elver wrote: >>>> On Fri, 26 Jun 2026 at 20:36, Paul E. McKenney wrote: >>>>> On Fri, Jun 26, 2026 at 08:40:50AM +0200, Christoph Hellwig wrote: >>>>>> On Sun, Jun 14, 2026 at 06:45:20PM +0530, Nilay Shroff wrote: >>>>>>> +++ b/drivers/nvme/host/multipath.c >>>>>>> @@ -231,8 +231,16 @@ bool nvme_mpath_clear_current_path(struct nvme_ns *ns) >>>>>>> bool changed = false; >>>>>>> int node; >>>>>>> >>>>>>> + /* >>>>>>> + * This helper is used by namespace failover/teardown and I/O policy >>>>>>> + * update paths. We only compare the head->current_path[] pointer value >>>>>>> + * and do not dereference the referenced namespace, so suppress the >>>>>>> + * context analysis warning for this lockless inspection of the >>>>>>> + * __rcu_guarded pointer. >>>>>>> + */ >>>>>>> for_each_node(node) { >>>>>>> - if (ns == rcu_access_pointer(head->current_path[node])) { >>>>>>> + if (context_unsafe(ns == >>>>>>> + rcu_access_pointer(head->current_path[node]))) { >>>>>> >>>>>> I think we need a helper for this, as for a simple pointer value >>>>>> comparison without a dereference we don't really need either >>>>>> rcu_access_pointer nor locking. >>>>>> >>>>>> Maybe somthing like a >>>>>> >>>>>> rcu_compare_pointer(rcu_pointer, nonrcu_pointer) >>>>>> >>>>>> ? >>>>> >>>>> We could provide something like this: >>>>> >>>>> #define rcu_compare_pointer(rcu_pointer, nonrcu_pointer) \ >>>>> context_unsafe(rcu_access_pointer(rcu_pointer) == (nonrcu_pointer)) >>>>> >>>>> Or maybe rcu_pointer_equals()? >>>>> >>>>> Marco, thoughts? >>>> >>>> I see 2 options: >>>> >>>> 1. rcu_compare_pointer / rcu_pointer_equals as proposed. It's more >>>> explicit but does add some friction during Context Analysis >>>> enablement. But this only makes sense if there are cases where >>>> rcu_access_pointer() should be used under the RCU reader lock, which >>>> led me to the next suggestion... >>>> >>>> 2. Redefine rcu_access_pointer() to just not require the RCU read-side >>>> lock to be held as: >>>> >>>>> #define rcu_access_pointer(p) context_unsafe(__rcu_access_pointer((p), __UNIQUE_ID(rcu), __rcu)) >>>> >>>> [ Or alternatively wrap __rcu_access_pointer() in context_unsafe() >>>> (similar to rcu_assign_pointer and friends). ] >>>> >>>> I think rcu_access_pointer() is in the same category as the other RCU >>>> pointer helpers, although currently only the pointer update helpers >>>> imply context_unsafe(); I think it might have been an oversight >>>> initially, and we should change rcu_access_pointer() to match. There >>>> should be no reason why an rcu_access_pointer() should be protected by >>>> the RCU read-side critical section, since it's not meant for >>>> dereferencing the pointer (that'd be a bug; its documentation also >>>> says "Return the value of the specified RCU-protected pointer, but >>>> omit the lockdep checks for being in an RCU read-side critical section >>>> [...]"). >>>> >>>> If you agree there should be no cases where an rcu_access_pointer() >>>> should be guarded by an RCU read-side critical section, then I think >>>> this is the simplest and correct design, and avoids expanding the RCU >>>> API. >>> >>> I don't know of any uses of rcu_access_pointer() within an RCU read-side >>> critical section, but code in a function that might be called both within >>> and outside of a critical section might well use rcu_access_pointer(). >>> In other words, it should be OK to use rcu_access_pointer() within an >>> RCU read-side critical section as well as outside of one. >> >> Thanks, yes, that's what I wanted to confirm; i.e. it's ok to use >> rcu_access_pointer() within and outside an RCU read-side critical >> section. >> >> In which case, my proposal (2) to make rcu_access_pointer() not warn >> on accessing __rcu_guarded pointers outside an RCU read-side critical >> section should be the simpler and more generic change (vs. adding a >> new rcu_pointer_equals() helper). > > As shown below? > > My guess is that this change makes it unnecessary to have a separate > RCU-protected-pointer comparison macro, but please let me know if I am > missing something. > > Thanx, Paul > > ------------------------------------------------------------------------ > > commit 32c1e63fee171f7ed8cc986ec64f576ee80bccab > Author: Paul E. McKenney > Date: Sun Jun 28 09:00:01 2026 -0700 > > rcu: Mark __rcu_access_pointer() as context_unsafe() > > A simple comparison of a pointer returned by rcu_access_pointer() results > in a context-analysis warning for lockless inspection of the RCU-protected > (also known as __rcu-protected) pointer. This can be suppressed by > placing context_unsafe() calls around calls rcu_access_pointer(), > but this is messy and distracting. This commit therefore wraps the > underlying __rcu_access_pointer() macro with a call to context_unsafe(), > thereby informing the context-analysis code that rcu_access_pointer() > may safely be invoked outside of an RCU read-side critical section. > > Reported-by: Christoph Hellwig > Suggested-by: Marco Elver > Signed-off-by: Paul E. McKenney > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 5e95acc33989b6..e40dc2e20c5b1f 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -490,12 +490,12 @@ context_unsafe( \ > */ > #define unrcu_pointer(p) __unrcu_pointer(p, __UNIQUE_ID(rcu)) > > -#define __rcu_access_pointer(p, local, space) \ > +#define __rcu_access_pointer(p, local, space) context_unsafe( \ > ({ \ > typeof(*p) *local = (typeof(*p) *__force)READ_ONCE(p); \ > rcu_check_sparse(p, space); \ > ((typeof(*p) __force __kernel *)(local)); \ > -}) > +}) ) > #define __rcu_dereference_check(p, local, c, space) \ > ({ \ > /* Dependency order vs. p above. */ \ I have tested the above patch with an __rcu_guarded pointer accessed outside an RCU read-side critical section while Clang context analysis is enabled. I can confirm that this change suppresses the context analysis warning when the pointer is accessed via rcu_access_pointer(). With that, if you send out this change, please add: Tested-by: Nilay Shroff Thanks, --Nilay