From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (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 D14183033FD for ; Wed, 22 Jul 2026 12:20:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784722802; cv=none; b=LtvIoyTw311baSzkk+XGVockz27h3szXKtVXyBqBFbmA8VzHB92vS1/QSTd+YHD4V/gG5gT/PrabLGPvsZgiwkTi01VfJEvM6xKthEU0Nl1QLBmW+ryglBqvfO++phMYkX02RmNPLWT9A9OL1c8DF7oQzBWaW9ELxtkyq2FrDLs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784722802; c=relaxed/simple; bh=WSdj0Xavhu60Z8z1irfyLQwo3AjkZi5zRqxhqNI2J8E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GbGKzwrMSPPRA93AY7xJ155/kmdftLpS/bLud+AI5MHo0wTiP0aJElu6L+ZJF6B9bbZNQEAehkinIL96FeMwbum52UQBL2N28HtgMlnm3V3K/z2A50gwcqBkCv+8Cw3FnLtf3YcJzxTBDwohE6A2fjvGWRKzgnAw3Em/lWZ+mak= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id DDFC468D1F; Wed, 22 Jul 2026 14:19:56 +0200 (CEST) Date: Wed, 22 Jul 2026 14:19:56 +0200 From: Christoph Hellwig To: Nilay Shroff Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, hch@lst.de, elver@google.com, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com, bvanassche@acm.org, gjoyce@linux.ibm.com Subject: Re: [PATCH v4 16/20] nvme: add context annotations in rdma.c Message-ID: <20260722121956.GI12774@lst.de> References: <20260713115444.465704-1-nilay@linux.ibm.com> <20260713115444.465704-17-nilay@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: <20260713115444.465704-17-nilay@linux.ibm.com> User-Agent: Mutt/1.5.17 (2007-11-01) On Mon, Jul 13, 2026 at 05:24:17PM +0530, Nilay Shroff wrote: > device_list and nvme_rdma_device::entry are protected by > device_list_mutex. Define device_list using > LIST_HEAD_GUARDED(device_list, device_list_mutex) and annotate > nvme_rdma_device::entry with __guarded_by(&device_list_mutex) so that > Clang's context analysis can validate accesses against the corresponding > locking requirements. > > Similarly, nvme_rdma_ctrl_list and nvme_rdma_ctrl::list are > protected by nvme_rdma_ctrl_mutex. Define nvme_rdma_ctrl_list using > LIST_HEAD_GUARDED(nvme_rdma_ctrl_list, nvme_rdma_ctrl_mutex) and > annotate nvme_rdma_ctrl::list with __guarded_by(&nvme_rdma_ctrl_mutex). > > It is safe to initialize nvme_rdma_ctrl::list while allocating the > controller object because the list entry has not yet been added to > nvme_rdma_ctrl_list. Annotate the initialization with context_unsafe() > to suppress the corresponding Clang context analysis warning. I still wish the lock context handling in clang could just do the right thing for fields initialized before the protecting lock, so we would not need all this unsafe magic. But to get things going for now: Reviewed-by: Christoph Hellwig