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 931443B4EAC
	for <linux-kernel@vger.kernel.org>; Thu,  9 Jul 2026 06:20:17 +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=1783578018; cv=none; b=MIn5xg1TDeXuMm9+fJJx7bh5WELpp7JspyfUCx340LEJIFGjL0s8Dlq3gLi1wzN+bCRBUkRMZmObgJruDkz1uq29H9T5u6/VahXffz4b7jCyTX5RxB/R7vNMRZTmf1bHKR96qCNI5kZzr9GiydAAoldERfE43a6PAZy3gKN3xow=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783578018; c=relaxed/simple;
	bh=TAyUzgGQ5ep/SS318LtwX/SC2QCBdKKYb+7D2pTBPWM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=VSHFXLsQh6KECNRqD6Aw4OVJ0HLA/FFYmaTbCTsHfEvTKGxKrepzi+QhlaLyfq5ybYqJiqgQMwz+paJvYbQrNz55GFdvq3BdlQHJI7HkizTnYYCyXAhiM0HfFTN1EbJLXUcQWxdPZSzFHw8ALADXdlqagToViPVEATlSSulrOSA=
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 1646F68BFE; Thu,  9 Jul 2026 08:20:15 +0200 (CEST)
Date: Thu, 9 Jul 2026 08:20:14 +0200
From: Christoph Hellwig <hch@lst.de>
To: Marco Elver <elver@google.com>
Cc: Christoph Hellwig <hch@lst.de>, Nilay Shroff <nilay@linux.ibm.com>,
	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 07/17] nvme: add Clang context annotations for
 nvme_subsystem::lock
Message-ID: <20260709062014.GA17526@lst.de>
References: <20260614131541.2017845-1-nilay@linux.ibm.com> <20260614131541.2017845-8-nilay@linux.ibm.com> <20260626064335.GG10731@lst.de> <0f3add6e-4e2c-4656-ad82-e86e18f6fcb7@linux.ibm.com> <20260629124703.GB23417@lst.de> <CANpmjNMCg_Qo9MVz3n_-gu6wRZp+y2uuuzjAdk+a1b-1J4LeNA@mail.gmail.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANpmjNMCg_Qo9MVz3n_-gu6wRZp+y2uuuzjAdk+a1b-1J4LeNA@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Tue, Jun 30, 2026 at 01:12:55AM +0200, Marco Elver wrote:
> Initialization of guarded objects has gone through a few iterations,

And all of them suck badly, with the current one being the worse.

> so I don't want to open that can of worms again. I think the
> infrastructure we have now provides various options (the scoped guard
> machinery isn't the only way). You could just write:
> 
> /* Initializes unpublished lock-guarded variables. */
> context_unsafe(
>     INIT_LIST_HEAD(&subsys->nsheads);
>     // ... other guarded var init in same block ...
> );

Using all these silly context makes it total mess unfortunately.