mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Ian Rogers <irogers@google.com>,
	acme@kernel.org, elver@google.com, namhyung@kernel.org
Cc: adrian.hunter@intel.com, james.clark@linaro.org,
	jolsa@kernel.org, justinstitt@google.com,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	ljs@kernel.org, llvm@lists.linux.dev, mingo@redhat.com,
	morbo@google.com, nathan@kernel.org, ndesaulniers@google.com,
	peterz@infradead.org
Subject: Re: [PATCH v2 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations
Date: Tue, 13 Oct 2026 15:52:33 -0700	[thread overview]
Message-ID: <3f57ddf4-b1a7-4c91-8983-c8cd83d0f25c@acm.org> (raw)
In-Reply-To: <20261013222622.1822619-1-irogers@google.com>

On 10/13/26 3:26 PM, Ian Rogers wrote:
> The perf tool previously added Clang thread-safety annotations in
> tools/perf/util/mutex.h (GUARDED_BY, LOCKABLE, EXCLUSIVE_LOCK_FUNCTION,
> UNLOCK_FUNCTION, etc.). Since then, the Linux kernel has adopted a
> unified set of static context analysis macros and attributes in
> include/linux/compiler-context-analysis.h (context_lock_struct,
> __guarded_by, __acquires, __releases, __must_hold, etc.).

New versions of a patch series should be posted as a new e-mail thread
instead of as a reply to an existing email thread. Additionally, posting
a new version of a patch series only four hours after the previous
version is way too soon.

The LLM that I asked to take a look at this patch series came up with
the feedback below. Please take a look at this feedback.

Thanks,

Bart.

--------------------------------------------------------------------------

Verdict: Needs Substantive Revision

While the overall goal and majority of the annotations are 
well-executed, several patches bundle distinct bug fixes with 
refactoring and annotation churn (violating the "one logical change per 
patch" rule).
Additionally, there are concurrency and lifetime subtleties in the newly 
introduced dsos__findnew_id() read-lock fast path and vdso.c, an 
unsynchronized benign data race in maps.c, and missing Fixes: 
attribution tags.

2. Critical & Concurrency Findings

A. Patch 07/10: Lock drop-and-reacquire race and unneeded 
re-invalidations in dsos__findnew_id()

In tools/perf/util/dsos.c:

struct dso *dsos__findnew_id(struct dsos *dsos, const char *name, const 
struct dso_id *id)
{
	struct dso *dso;
	down_read(&dsos->lock);
	dso = __dsos__find_id(dsos, name, id, false, /*write_locked=*/false);
	if (dso && !dso__needs_improve_id(dso, id)) {
		up_read(&dsos->lock);
		return dso;
	}
	up_read(&dsos->lock);
	down_write(&dsos->lock);
	if (dso)
		__dso__improve_id(dso, id);
	else
		dso = __dsos__findnew_id(dsos, name, id);
	up_write(&dsos->lock);
	return dso;
}
Issue: If dso is found under down_read but needs ID improvement 
(dso__needs_improve_id(dso, id) == true), up_read() releases the lock. 
Before down_write() is acquired, another thread may have acquired 
down_write() and already improved the DSO's ID with the identical or 
better info.
Consequence: When down_write() is acquired, __dso__improve_id(dso, id) 
is executed unconditionally without re-checking dso__needs_improve_id(). 
While updating fields is mostly idempotent, __dso__improve_id() sets 
dsos->sorted = false;, unnecessarily degrading subsequent read lookups 
to qsort().
Fix: Re-check dso__needs_improve_id(dso, id) under down_write(). If no 
improvement is needed, avoid calling __dso__improve_id().
B. Patch 07/10: Unnecessary lock churn and array sort invalidation in vdso.c

In tools/perf/util/vdso.c:

static struct dso *__machine__addnew_vdso(struct machine *machine, const 
char *short_name, const char *long_name)
{
	struct dso *dso;
	dso = dso__new(short_name);
	if (dso != NULL) {
		dsos__add(&machine->dsos, dso);
		dso__set_long_name(dso, long_name, false);
	}
Issue: Calling dsos__add() followed by dso__set_long_name() causes two 
separate down_write(&machine->dsos.lock) acquisitions in immediate 
succession. Worse, dsos__add() inserts the DSO into the array ordered by 
its current short_name. Immediately afterwards, dso__set_long_name() 
mutates the name and explicitly sets dsos->sorted = false; (lines 1528 
in dso.c).
Fix: Set the long name before adding the DSO to dsos (matching the 
pattern used in dsos__findnew_module_dso() in util/dsos.c):

	dso = dso__new(short_name);
	if (dso != NULL) {
		dso__set_long_name(dso, long_name, false);
		dsos__add(&machine->dsos, dso);
	}

This requires only a single write lock acquisition in dsos__add() and 
keeps dsos->sorted = true.

C. Patch 10/10: Unsynchronized concurrent write in maps__find_by_name()

In tools/perf/util/maps.c:

struct map *maps__find_by_name(struct maps *maps, const char *name)
{
...
	while (!done) {
		down_read(maps__lock(maps));
...
		/* Second search sorted array. */
		if (!done && maps__maps_by_name_sorted(maps)) {
			struct map **mapp =
				bsearch(name, maps__maps_by_name(maps), __maps__nr_maps(maps),
					sizeof(*mapp), map__strcmp_name);
			if (mapp) {
				result = map__get(*mapp);
				i = mapp - maps__maps_by_name(maps);
				RC_CHK_ACCESS(maps)->last_search_by_name_idx = i;
			}
			done = true;
		}
		up_read(maps__lock(maps));
Issue: last_search_by_name_idx is written while holding only 
down_read(maps__lock(maps)). Because multiple reader threads execute 
maps__find_by_name() concurrently, this is a concurrent write race 
(which is why last_search_by_name_idx could not be annotated with 
__guarded_by(&lock)).
Consequence: Under TSAN or strict memory models, unsynchronized 
conflicting writes cause data races.
Suggestion: Use WRITE_ONCE()/data_race() on the assignment, or annotate 
last_search_by_name_idx with a brief comment explaining that this is an 
intentional, benign unlocked cache update.

3. Patch Architecture & Organization Findings

Per Documentation/process/submitting-patches.rst ("Separate each logical 
change into a separate patch"):

Patch 07/10 mixes 4 distinct logical changes:

Bug fix: Fixing the unlocked __dsos__add() call in __machine__addnew_vdso().
Performance optimization: Adding the read-lock fast path in 
dsos__findnew_id().
Refactoring: Replacing _dso__data_open_lock and pthread_once with 
DEFINE_MUTEX(dso__data_open_lock).
Annotations: Adding static context analysis macros across dso.c, dso.h, 
dsos.c, dsos.h.
Recommendation: Split this patch into at least 3 patches:
Standalone bug fix for vdso.c with a Fixes: tag (see metadata below).
Standalone performance optimization for dsos__findnew_id().
DSO/DSOs lock annotations and mutex cleanup.

Patch 09/10 bundles three disparate subsystems plus a bug fix:

Combines perf config, intel-tpebs, and perf_env.
Includes a real bug fix: fixing an unlocked read of tpebs_reader_thread 
after releasing tpebs_mtx in tpebs_stop().
Recommendation: Split the intel-tpebs race fix into its own commit with 
a Fixes: tag. Split the remaining annotations into separate commits per 
subsystem (perf config, perf intel-tpebs, and perf env).



  parent reply	other threads:[~2026-10-13 22:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 18:24 [PATCH v1 " Ian Rogers
2026-10-13 18:24 ` [PATCH v1 01/10] compiler-context-analysis: Avoid unused parameter warning in _context_unsafe_alias() Ian Rogers
2026-10-13 19:44   ` Bart Van Assche
2026-10-13 22:10     ` Ian Rogers
2026-10-13 22:14       ` Bart Van Assche
2026-10-13 22:26         ` Ian Rogers
2026-10-13 22:47     ` Bart Van Assche
2026-10-13 22:59       ` Ian Rogers
2026-10-13 18:24 ` [PATCH v1 02/10] tools headers compiler: Synchronize compiler_types.h with the kernel sources Ian Rogers
2026-10-13 18:24 ` [PATCH v1 03/10] tools headers: Synchronize linux/compiler-context-analysis.h " Ian Rogers
2026-10-13 18:24 ` [PATCH v1 04/10] perf mutex: Use kernel style compiler-context-analysis.h annotations Ian Rogers
2026-10-13 18:24 ` [PATCH v1 05/10] perf build: Enable additional Clang thread-safety flags Ian Rogers
2026-10-13 18:24 ` [PATCH v1 06/10] perf comm: Add __guarded_by annotations to struct comm_strs Ian Rogers
2026-10-13 18:24 ` [PATCH v1 07/10] perf dso: Fix unlocked __dsos__add() in vdso and expand lock annotations Ian Rogers
2026-10-13 18:24 ` [PATCH v1 08/10] perf thread: Expand context analysis annotations to threads and namespaces_lock Ian Rogers
2026-10-13 18:24 ` [PATCH v1 09/10] perf config, intel-tpebs, env: Add __guarded_by and __must_hold annotations Ian Rogers
2026-10-13 18:24 ` [PATCH v1 10/10] perf maps: Add context analysis annotations Ian Rogers
2026-10-13 22:26 ` [PATCH v2 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations Ian Rogers
2026-10-13 22:26   ` [PATCH v2 01/10] compiler-context-analysis: Avoid unused parameter warning in _context_unsafe_alias() Ian Rogers
2026-10-14  5:38     ` Marco Elver
2026-10-13 22:26   ` [PATCH v2 02/10] tools headers compiler: Synchronize compiler_types.h with the kernel sources Ian Rogers
2026-10-13 22:26   ` [PATCH v2 03/10] tools headers: Synchronize linux/compiler-context-analysis.h " Ian Rogers
2026-10-13 22:26   ` [PATCH v2 04/10] perf mutex: Use kernel style compiler-context-analysis.h annotations Ian Rogers
2026-10-13 22:26   ` [PATCH v2 05/10] perf build: Enable additional Clang thread-safety flags Ian Rogers
2026-10-13 22:26   ` [PATCH v2 06/10] perf comm: Add __guarded_by annotations to struct comm_strs Ian Rogers
2026-10-13 22:26   ` [PATCH v2 07/10] perf dso: Fix unlocked __dsos__add() in vdso and expand lock annotations Ian Rogers
2026-10-13 22:26   ` [PATCH v2 08/10] perf thread: Expand context analysis annotations to threads and namespaces_lock Ian Rogers
2026-10-13 22:26   ` [PATCH v2 09/10] perf config, intel-tpebs, env: Add __guarded_by and __must_hold annotations Ian Rogers
2026-10-13 22:26   ` [PATCH v2 10/10] perf maps: Add context analysis annotations Ian Rogers
2026-10-13 22:52   ` Bart Van Assche [this message]
2026-10-13 23:09     ` [PATCH v2 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations Ian Rogers
2026-10-13 23:18       ` Bart Van Assche
2026-10-13 23:26         ` Ian Rogers

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=3f57ddf4-b1a7-4c91-8983-c8cd83d0f25c@acm.org \
    --to=bvanassche@acm.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=elver@google.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=justinstitt@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®