From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DD6C3F1AA7 for ; Tue, 30 Jun 2026 10:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782815892; cv=none; b=c5tGbpyY2d8AO68oGr+/iIAktxYhkXtMxc/rB+qYUsGWtDTBlYvwYQSamnXEl5RiHJCIkkfpLMmoo6jSWZf7qckoFys0c7sEv2nOD3xLqD6B4A/AcZk1yKFdr6k2Lm7rXfxonbkkoBmkgt4PFYgxovsxtUXCY2pmNpGHm3QsiWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782815892; c=relaxed/simple; bh=PBt++vSKo04WVFXJJ6ySicCsLJ/Ct9qAiltctPdZvCg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QbBgd0mPLaRETMcRyI4QdFH3jLByp7uKLpLWz7NaNJ8no+tNGUfR2DZPOqb9zZEkboqmYJ4r0w7e8KksJszACLTgZzRGNofPuH1qI7tqqxNZIBsOwg3acWmHhqmaEb3eugguRTE/FEfhhKvjj7y3sqwDHmtFVUN8KgfGs4wcs2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Sndmr1ee; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Sndmr1ee" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-493a54b80a5so34504005e9.2 for ; Tue, 30 Jun 2026 03:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782815889; x=1783420689; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3W15pG85C5FxVGgdo4xnnSJkKUbelIMkLyPB5cfY4Lw=; b=Sndmr1ee7kq6pHduZQ/50YhY7ajJHnQDfkLQ4OtwxiPefCCcknzCv51QIrdmsE+xrU GcERX8lNUGEJnBEc2C7YGCuei2AsWXG/P+AyroduUB5YHGIHdXFpntW4JcBDNgZERDeQ +/oFyPaJcGWaf5YjQ1z+0DRmNokCTSlRjtbnGl+p8p3OwE/X2qLqQiEQh3ZfzQ7SlA+f HTEnQqlCqJPnsTMpeL0f88Dvb9qs849tRLKhVlkTsXReeMKlN8g8EHRmBI0kvhwkFSAB 6X+JdkfpjLsDStx0NkGgSb52bHJalEdLXkVLGmzejYy2C28httshTc3m5yJ7kK/rB6nP HcAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782815889; x=1783420689; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3W15pG85C5FxVGgdo4xnnSJkKUbelIMkLyPB5cfY4Lw=; b=LEKED48DEq3r7wKgwqoa6wQEmrDj5ekvvKVIpvijBzSitLzKM+RGFfLeWYQLDtEWJ+ /IU/xzl7yAjRgsYCmCgaq2ugeXYi+YiYGhGRtXGSS0kVi952oiE1HWkBzrS80rkk86ez e+iFhP/uahVC9V308uL3pT9CwQg9IQJN9EgQEqJrLFl9tmcOY3C1YNUzkHMpC7CPEq4U OpWx6Dt5bCfOOF21Rux14QzuzWtOqWc+jIZ1yTpVl2xlA9JjDRBGUwj22W8JOf2uwNw1 9S1FXpZA+M+XpkMdXf21X5hYQeM7djTRMI1VCYCiTqiAOhMABSf3LYt51qiVPSGSslZG xAsA== X-Forwarded-Encrypted: i=1; AFNElJ+0Mk8rXoMY2tTp3MlsKRoA5g4mcRDDN2LQD1aUTCRdh1dPAxvp2epN+QweHOmJZOKwveNTT64FjNgSmD8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyl5X4Rg81i2+AfCIqQcfSKhQn5xelkrkaEhzusngvLd0tIPtpe Fn4OmSC4uXBANjeuVjO32sWXjfgDr73Lfod2B/0XugH5QSdozi69DBts6GpYSlb0gTlgIxsBsY4 MuYicaSngw98= X-Gm-Gg: AfdE7cmttXLAR4K8AuncOpgQUIZbKYl/B4p+ilPP/x/bAuXyBadA45ADOz/L+wmQ8BL uiXVhdqYd8lYCC9yzoOKH7P8YSwGGz06FeOeA1o7V0v+ntfvEDek2ed37/Cd5Kna4NEiiPSjLo0 F+SiUp9O6wna+7Zqt+AVtIFdo9zpVmWM2JYQhgIDTDCJY3XnI8sKIEMQekB8JrGFkRhSew/LuUm bPeBFuiThw37RX2a/GGL4gY0XnwauVXtgeRlpZ8CtBSyQFoIJdw6gLeRD6osqbizo/n6LKrZs2G oClsx1X4bda59TCwU5dpf95OLGnF0IKGZTP81CAvPuSm0gdhKrjGilJvh6wfM/wae37lpa7XQCr wZFkKbn0DO5rFniPLs/kCOEU/ePuBiB+65Vj7pT+k8xZBOu98RorqrCxeGjQGP/GQhyhTEnohwg ZPz+tBfwDFS2Tz9TEPN+Fo0RcqJSrMA1w6XLlvIDMAK2Spo3GenH6s9UbVeWEa X-Received: by 2002:a05:600c:a317:b0:493:af56:8e64 with SMTP id 5b1f17b1804b1-493b82b9ea0mr43517025e9.32.1782815888152; Tue, 30 Jun 2026 03:38:08 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:2834:9:466b:c391:2be8:331a]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493b8cd303csm57386185e9.6.2026.06.30.03.38.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2026 03:38:07 -0700 (PDT) Date: Tue, 30 Jun 2026 12:38:01 +0200 From: Marco Elver To: Nilay Shroff 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 Subject: Re: [PATCHv2 14/17] nvme: fix Clang context analysis warning in rdma.c Message-ID: References: <20260614131541.2017845-1-nilay@linux.ibm.com> <20260614131541.2017845-15-nilay@linux.ibm.com> <20260626064916.GC11106@lst.de> <20260629125054.GC23695@lst.de> <4fba3fdb-73df-4cd0-9318-00ff5a1e4fe6@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fba3fdb-73df-4cd0-9318-00ff5a1e4fe6@linux.ibm.com> User-Agent: Mutt/2.3.2 (2026-04-26) On Tue, Jun 30, 2026 at 03:05PM +0530, Nilay Shroff wrote: > On 6/30/26 4:17 AM, Marco Elver wrote: > > On Mon, 29 Jun 2026 at 14:50, Christoph Hellwig wrote: > > > > > > On Fri, Jun 26, 2026 at 09:01:20PM +0530, Nilay Shroff wrote: > > > > > Does switching to list_empty_careful fix this? If not, does > > > > > list_empty_careful need annotations to make this work? > > > > > > > > > > > > > I tried using list_empty_careful() but clang still throws the > > > > same warning. And yes it needs same annotation to suppress > > > > the warning. > > > > > > Sounds like we should have annotations (or just use of data_race) > > > in list_empty_careful, as it is designed to be used without holding > > > the relevant lock used for modifications? > > > > Given list_empty_careful() is a real inline function (not a macro), > > you can just add __no_context_analysis to list_empty_careful(), which > > should also suppress warnings about pointer-to-guarded-variable being > > passed as an argument into it. data_race() wouldn't work, as the > > warning is generated in the caller, but when the attribute is added to > > the callee, it also suppresses warnings about arguments in the caller. > > That sounds reasonable. So you're suggesting adding __no_context_analysis > to list_empty_careful(). If we agree that's the right approach, I think > it would make sense as a separate infrastructure patch rather than embedding > it in an NVMe-specific change. So are you planning to send such a patch? See patch below; to avoid more dependency issues for you, I suggest you pick it up and carry it as part of this series unless someone else wants it before for other reasons. Only lightly tested, please test. ------ >8 ------ From: Marco Elver Date: Tue, 30 Jun 2026 12:01:26 +0200 Subject: [PATCH] list: Permit context-unguarded access with list_empty_careful() With Context Analysis (viz. Clang's Thread Safety Analysis), list_heads that are __guarded_by(..) require holding the appropriate context lock when accessing and manipulating them via the list API. Because Clang's warning diagnostics do not perform inter-procedural analysis, this is enforced by Clang with -Wthread-safety-pointer in the caller at the call boundary; a warning is produced when passing a pointer to a guarded variable without holding the appropriate context locks: warning: passing pointer to variable 'list' requires holding [...] [-Wthread-safety-pointer] if (list_empty(&ctrl->list)) An exception is list_empty_careful(), which is like list_empty(), except that it is permitted to use without holding any context lock (carefully). Mark list_empty_careful() __context_unsafe, which disables context analysis within list_empty_careful(), but also suppresses warnings generated in callers related to its pointer arguments. Signed-off-by: Marco Elver --- include/linux/list.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/list.h b/include/linux/list.h index 09d979976b3b..ba3c255f6112 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -436,6 +436,7 @@ static inline void list_del_init_careful(struct list_head *entry) * if another CPU could re-list_add() it. */ static inline int list_empty_careful(const struct list_head *head) + __context_unsafe(/* intentional lockless access to @head */) { struct list_head *next = smp_load_acquire(&head->next); return list_is_head(next, head) && (next == READ_ONCE(head->prev)); -- 2.55.0.rc2.803.g1fd1e6609c-goog