Re: [PATCH] once_lite: Simplify condition handling and fix context analysis

[Jan Kara]

On Tue 08-09-26 00:17:34, Marco Elver wrote:
> On Tue, 8 Sept 2026 at 00:13, Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> >
> > On Thu, Sep 03, 2026 at 10:16:38AM +0000, Marco Elver wrote:
> > > When WARN_ON_ONCE() wraps a conditional lock acquisition (such as
> > > down_write_trylock()) on architectures relying on DO_ONCE_LITE_IF()
> > > (e.g. arm), Clang's context analysis (Thread Safety Analysis) failed
> > > with a false positive:
> > >
> > >   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)))
> > >         |             ^
> > >
> > > This happens because DO_ONCE_LITE_IF() branches on __ONCE_LITE_IF()'s
> > > return value (__ret_once), creating an intermediate branch merge point
> > > where the lock may or may not be held depending on whether the once-flag
> > > (__already_done) was already set. Because the merge branch condition is
> > > __ret_once rather than the trylock predicate (__ret_do_once), Clang
> > > cannot reconcile the lockset at the branch merge points.
> > >
> > > Fix it by refactoring __ONCE_LITE_IF() into an unconditional
> > > __ONCE_LITE() primitive and redefining __ONCE_LITE_IF(condition) as:
> > >
> > >   (unlikely(condition) && __ONCE_LITE())
> > >
> > > This simplifies the implementation, short-circuits evaluation so that
> > > __ONCE_LITE() is not called when the condition is false, and ensures
> > > that DO_ONCE_LITE_IF() only enters __ONCE_LITE() when __ret_do_once is
> > > true.
> > >
> > > Reported-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> > > Link: https://lore.kernel.org/all/20260903072759.GA1750084@ax162/
> > > Signed-off-by: Marco Elver <elver@xxxxxxxxxx>
> >
> > Thanks, this fixes that warning for me across all my builds.
> >
> > Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx> # build
> 
> Thanks! I think this is one of those orphaned files - which tree can
> this go through? Can it go through your tree, unless Jan already
> picked it up with the other fix?

If Nathan can take it through his tree, that would be great, otherwise I
can take it through mine. Just let me know.

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