All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Timothy Day <timday@thelustrecollective.com>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.com>,
	Marco Elver <elver@google.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/9] ext2: fix ext2_xattr_delete_inode() context analysis warning
Date: Mon, 13 Jul 2026 10:32:56 -0400	[thread overview]
Message-ID: <alT2yHlfzhTZ9n4T@mit.edu> (raw)
In-Reply-To: <20260712165610.366474-2-timday@thelustrecollective.com>

On Sun, Jul 12, 2026 at 12:56:02PM -0500, Timothy Day wrote:
> Clang reports the following warning when context analysis is enabled:
> 
> fs/ext2/xattr.c:829:6: error: rw_semaphore 'EXT2_I().xattr_sem' is not \
>   held on every path through here [-Werror,-Wthread-safety-analysis]
>   829 |         if (WARN_ON_ONCE(!down_write_trylock(&EXT2_I(inode)->xattr_sem)))
>       |             ^
> 
> When WARN_ON_ONCE() wraps down_write_trylock(), it adds an unlikely()
> annotation which hides the conditional acquire annotation from Clang's
> context analysis. This triggers a false positive. Pull the trylock out
> of the macro to silence this warning.

Does this mean that using Clang's context analysis means that we can't
use unlikely()?  That seems.... unfortunate.  Is there any other way
we can fix the false positive?  Even disabling unlikely() if and only
if Clang context analysis is enabled might be a better choice, since
we don't necessarily need to build with context analysis enabled when
building a production kernel.

				- Ted

  reply	other threads:[~2026-07-13 14:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12 16:56 [PATCH v1 0/9] Support Clang context analysis for ext2 Timothy Day
2026-07-12 16:56 ` [PATCH v1 1/9] ext2: fix ext2_xattr_delete_inode() context analysis warning Timothy Day
2026-07-13 14:32   ` Theodore Tso [this message]
2026-07-13 16:44     ` Timothy Day
2026-07-13 22:27       ` Marco Elver
2026-07-13 22:56         ` Marco Elver
2026-07-14  2:26       ` Theodore Tso
2026-07-14  4:17         ` Timothy Day
2026-07-14  4:49           ` Theodore Tso
2026-07-12 16:56 ` [PATCH v1 2/9] ext2: mark s_next_generation as guarded by s_next_gen_lock Timothy Day
2026-07-12 16:56 ` [PATCH v1 3/9] ext2: annotate ext2_update_dynamic_rev() as requiring s_lock Timothy Day
2026-07-12 16:56 ` [PATCH v1 4/9] ext2: mark statfs overhead cache as guarded by s_lock Timothy Day
2026-07-12 16:56 ` [PATCH v1 5/9] ext2: mark s_mount_state " Timothy Day
2026-07-12 16:56 ` [PATCH v1 6/9] ext2: annotate ext2_init_block_alloc_info() as requiring truncate_mutex Timothy Day
2026-07-12 16:56 ` [PATCH v1 7/9] ext2: annotate block-mapping helpers " Timothy Day
2026-07-12 16:56 ` [PATCH v1 8/9] ext2: annotate s_rsv_window_root as requiring s_rsv_window_lock Timothy Day
2026-07-12 16:56 ` [PATCH v1 9/9] ext2: enabled context analysis support for ext2 filesystem Timothy Day
2026-07-14 17:27 ` [PATCH v1 0/9] Support Clang context analysis for ext2 Jan Kara

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=alT2yHlfzhTZ9n4T@mit.edu \
    --to=tytso@mit.edu \
    --cc=elver@google.com \
    --cc=jack@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timday@thelustrecollective.com \
    /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.