Re: [PATCH v2 0/8] Support Clang context analysis for ext2

[Jan Kara]

On Thu 03-09-26 14:06:22, Marco Elver wrote:
> On Thu, 3 Sept 2026 at 13:06, Jan Kara <jack@xxxxxxx> wrote:
> >
> > On Thu 03-09-26 12:34:34, Marco Elver wrote:
> > > On Thu, 3 Sept 2026 at 09:28, Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> > > >   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'
> > >
> > > sbi was just allocated, and EXT2_SB(sb) and sbi are pointing to the
> > > same object (unless I misread the code), but the compiler can't tell
> > > since aliases can't be tracked through non-local objects. So that
> > > scoped_guard could just become:
> > >
> > >   scoped_guard(spinlock, &EXT2_SB(sb)->s_rsv_window_lock) {
> > >   ...
> > >
> > > But I'll leave that to Jan and Tim.
> >
> > Yes, at the beginning of ext4_fill_super() we do:
> >
> >         sbi = kzalloc_obj(*sbi);
> >         ...
> >         sb->s_fs_info = sbi;
> >
> > and EXT2_SB(sb) is just sb->s_fs_info. Are you saying that clang is not
> > able to infer that sb->s_fs_info and sbi are still pointing to the same
> > memory later in the function where we do scoped_guard()?
> 
> Yes - alias tracking is only done through local aliases. sb is
> non-local, along with additional member indirection; unfortunately,
> the C language doesn't give us the guarantees that it wasn't modified
> somewhere in between, say after a function call (this rule is applied
> also for local aliases if clang sees that they "escape" their local
> scope via non-const pointer to pointer).

Hrm, ok, understood (but still it's annoying ;)). I've pushed out the patch
with the suggested fixup.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR