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 7478E2FE56B; Fri, 19 Sep 2025 14:08: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=1758290901; cv=none; b=YQIIZ7n7nYmnvarCYHUvG8czj7M0Vsud6ppuT1IIfKIAZG3rxmoBUZmwdOSJ9bC0XGyx/qAJe8vG7qRryHK+u0vYK7iRAkNnY8qEJVJnESkJaLuSXpVThc123yuEQ25krp2f5+Do9x3qqBwB9bdNB0tXvv+0l0Q+BgIcIVNGCYQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758290901; c=relaxed/simple; bh=NUPh0JtwrHiUi7p6EEg2cxsqqXnH3TPGQmlGZJXCRYA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g8xt6yAVl6ZemyHdBe/xI3dYblYQu+qpECPFJdDPmcwT1n1zRmMYzr4shzyNAAGwQgCHT4qFAD4UhH1qQCCUXVXf1WzrVpxHmxz30WuaTe7g5lni97jd9k6O80jvQTMyeSU7bBk0vwTMto5vn3LJD+M0GiShfci98QrxmwwA2zY= 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 BBAB368AA6; Fri, 19 Sep 2025 16:08:03 +0200 (CEST) Date: Fri, 19 Sep 2025 16:08:03 +0200 From: Christoph Hellwig To: Nathan Chancellor Cc: Christoph Hellwig , Marco Elver , Peter Zijlstra , Boqun Feng , Ingo Molnar , Will Deacon , "David S. Miller" , Luc Van Oostenryck , "Paul E. McKenney" , Alexander Potapenko , Arnd Bergmann , Bart Van Assche , Bill Wendling , Dmitry Vyukov , Eric Dumazet , Frederic Weisbecker , Greg Kroah-Hartman , Herbert Xu , Ian Rogers , Jann Horn , Joel Fernandes , Jonathan Corbet , Josh Triplett , Justin Stitt , Kees Cook , Kentaro Takeda , Lukas Bulwahn , Mark Rutland , Mathieu Desnoyers , Miguel Ojeda , Neeraj Upadhyay , Nick Desaulniers , Steven Rostedt , Tetsuo Handa , Thomas Gleixner , Thomas Graf , Uladzislau Rezki , Waiman Long , kasan-dev@googlegroups.com, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-sparse@vger.kernel.org, llvm@lists.linux.dev, rcu@vger.kernel.org Subject: Re: [PATCH v3 00/35] Compiler-Based Capability- and Locking-Analysis Message-ID: <20250919140803.GA23745@lst.de> References: <20250918140451.1289454-1-elver@google.com> <20250918141511.GA30263@lst.de> <20250918174555.GA3366400@ax162> Precedence: bulk X-Mailing-List: linux-doc@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: <20250918174555.GA3366400@ax162> User-Agent: Mutt/1.5.17 (2007-11-01) On Thu, Sep 18, 2025 at 10:45:55AM -0700, Nathan Chancellor wrote: > On Thu, Sep 18, 2025 at 04:15:11PM +0200, Christoph Hellwig wrote: > > On Thu, Sep 18, 2025 at 03:59:11PM +0200, Marco Elver wrote: > > > A Clang version that supports `-Wthread-safety-pointer` and the new > > > alias-analysis of capability pointers is required (from this version > > > onwards): > > > > > > https://github.com/llvm/llvm-project/commit/b4c98fcbe1504841203e610c351a3227f36c92a4 [3] > > > > There's no chance to make say x86 pre-built binaries for that available? > > I can use my existing kernel.org LLVM [1] build infrastructure to > generate prebuilt x86 binaries. Just give me a bit to build and upload > them. You may not be the only developer or maintainer who may want to > play with this. That did work, thanks. I started to play around with that. For the nvme code adding the annotations was very simply, and I also started adding trivial __guarded_by which instantly found issues. For XFS it was a lot more work and I still see tons of compiler warnings, which I'm not entirely sure how to address. Right now I see three major classes: 1) locks held over loop iterations like: fs/xfs/xfs_extent_busy.c:573:26: warning: expecting spinlock 'xfs_group_hold(busyp->group)..xg_busy_extents->eb_lock' to be held at start of each loop [-Wthread-safety-analysis] 573 | struct xfs_group *xg = xfs_group_hold(busyp->group); | ^ fs/xfs/xfs_extent_busy.c:577:3: note: spinlock acquired here 577 | spin_lock(&eb->eb_lock); | ^ This is perfectly find code and needs some annotations, but I can't find any good example. 2) Locks on returned objects, which can be NULL. I.e., something like crossover of __acquire_ret and __cond_acquires 3) Wrappers that take multiple locks conditionally We have helpers that take different locks in the same object based on the arguments like xfs_ilock() or those that take the same lock and a variable number of objects like xfs_dqlockn based on input and sorting. The first are just historic and we might want to kill them, but the sorting of objects to acquire locks in order thing is a pattern in various places including the VFS, so we'll need some way to annotate it.