From: Nathan Chancellor <nathan@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Timothy Day <timday@thelustrecollective.com>,
linux-ext4@vger.kernel.org, Jan Kara <jack@suse.com>,
Marco Elver <elver@google.com>, Theodore Tso <tytso@mit.edu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/8] Support Clang context analysis for ext2
Date: Thu, 3 Sep 2026 00:27:59 -0700 [thread overview]
Message-ID: <20260903072759.GA1750084@ax162> (raw)
In-Reply-To: <xiymqvu5la6h63umrp6upnzbl3xjjcacuyxg76xp4labnrioyj@xowfpjlhfrzh>
On Tue, Aug 18, 2026 at 11:58:20AM +0200, Jan Kara wrote:
> On Tue 11-08-26 12:03:28, Timothy Day wrote:
> > This description is mostly copied from v1:
> >
> > This series adds annotations for Clang's context analysis to ext2.
> > Clang context analysis was recently added in a series by Marco
> > Elver [1]. This allows the compiler to validate different
> > locking patterns at compile time.
> >
> > This series enables context analysis, fixes pre-existing warnings,
> > and adds new annotations. It is inspired by similar series in the
> > block layer (NVMe host driver, for example [2]).
> >
> > I'm starting with ext2 since it's smaller and simpler compared to
> > ext4/btrfs/etc. After ext2, I'd be interested in converting the
> > other filesystems and infrastructure code in fs/. I think the ultimate
> > goal would be to enable this by default across all of fs/.
> >
> > The series was built and tested with Clang 23 with
> > CONFIG_WARN_CONTEXT_ANALYSIS enabled. I based on 7.2-rc7.
>
> Thanks for the patches! They look good to me. Once the merge window is over
> I'll queue them to my tree. The only thing I'm not fully sure is how much I
> like the spinlock_init scoped guards - they looked quite confusing to me at
> the first sight (as much as I understand the convenience, conceptually how
> can initialization of a global lock be scoped?). I'll sleep over it, maybe
> I'll change them to just spinlock_init() + scoped_guard for the lock itself
> or maybe I'll get used to them. Anyway, no action on your side needed :).
This series is now in -next, where I see the following warnings (or errors with
CONFIG_WERROR=y / W=e) with various configurations, such as ARCH=arm
allmodconfig, when building with LLVM 23.1.0
fs/ext2/xattr.c:825:6: error: rw_semaphore 'EXT2_I().xattr_sem' is not held on every path through here [-Werror,-Wthread-safety-analysis]
825 | if (WARN_ON_ONCE(!down_write_trylock(&EXT2_I(inode)->xattr_sem)))
| ^
include/asm-generic/bug.h:180:2: note: expanded from macro 'WARN_ON_ONCE'
180 | DO_ONCE_LITE_IF(condition, WARN_ON, 1)
| ^
include/linux/once_lite.h:30:7: note: expanded from macro 'DO_ONCE_LITE_IF'
30 | if (__ONCE_LITE_IF(__ret_do_once)) \
| ^
include/linux/once_lite.h:23:3: note: expanded from macro '__ONCE_LITE_IF'
23 | unlikely(__ret_once); \
| ^
include/linux/compiler.h:77:22: note: expanded from macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
fs/ext2/xattr.c:825:20: note: rw_semaphore acquired here
825 | if (WARN_ON_ONCE(!down_write_trylock(&EXT2_I(inode)->xattr_sem)))
| ^
fs/ext2/super.c:1149:3: error: calling function 'ext2_rsv_window_add' requires holding spinlock 'EXT2_SB(sb).s_rsv_window_lock' exclusively [-Werror,-Wthread-safety-precise]
1149 | ext2_rsv_window_add(sb, &sbi->s_rsv_window_head);
| ^
fs/ext2/super.c:1149:3: note: found near match '_res->s_rsv_window_lock'
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-09-03 7:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 16:03 [PATCH v2 0/8] Support Clang context analysis for ext2 Timothy Day
2026-08-11 16:03 ` [PATCH v2 1/8] ext2: mark s_next_generation as guarded by s_next_gen_lock Timothy Day
2026-08-11 16:03 ` [PATCH v2 2/8] ext2: annotate ext2_update_dynamic_rev() as requiring s_lock Timothy Day
2026-08-11 16:03 ` [PATCH v2 3/8] ext2: mark statfs overhead cache as guarded by s_lock Timothy Day
2026-08-11 16:03 ` [PATCH v2 4/8] ext2: mark s_mount_state " Timothy Day
2026-08-11 16:03 ` [PATCH v2 5/8] ext2: annotate ext2_init_block_alloc_info() as requiring truncate_mutex Timothy Day
2026-08-11 16:03 ` [PATCH v2 6/8] ext2: annotate block-mapping helpers " Timothy Day
2026-08-11 16:03 ` [PATCH v2 7/8] ext2: annotate s_rsv_window_root as requiring s_rsv_window_lock Timothy Day
2026-08-11 16:03 ` [PATCH v2 8/8] ext2: enable context analysis support for ext2 filesystem Timothy Day
2026-08-12 11:14 ` [PATCH v2 0/8] Support Clang context analysis for ext2 Marco Elver
2026-08-18 9:58 ` Jan Kara
2026-09-03 7:27 ` Nathan Chancellor [this message]
2026-09-03 10:34 ` Marco Elver
2026-09-03 11:06 ` Jan Kara
2026-09-03 12:06 ` Marco Elver
2026-09-03 12:43 ` Jan Kara
2026-09-11 20:01 ` Timothy Day
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260903072759.GA1750084@ax162 \
--to=nathan@kernel.org \
--cc=elver@google.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=timday@thelustrecollective.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.