Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/6] perf lock contention: Share common BPF and lock type definitions in lock_data.h
Date: Sat, 17 Oct 2026 17:31:22 +0000	[thread overview]
Message-ID: <sashiko-outbox-175709@kernel.org> (raw)
In-Reply-To: <20261017171437.2066343-2-irogers@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf lock: get_lock_owner() conflates waiter and owner rwsem flags
--

commit bc2b5a2f6b16ec842dcc1aeeebcdc72f657fd11b
Author: Ian Rogers <irogers@google.com>

perf lock contention: Share common BPF and lock type definitions in lock_data.h

This commit moves lock_type_table, LCB_F_* flags, CO-RE structs, and common
BPF lock helpers into tools/perf/util/bpf_skel/lock_data.h so they can be
shared with BPF sample filtering. It also extends get_lock_owner() to support
rt_mutex and check writer-ownership and handoff flags.

> diff --git a/tools/perf/util/bpf_skel/lock_data.h b/tools/perf/util/bpf_skel/lock_data.h
> index 652e114e6b877..bf39128e0be15 100644
> --- a/tools/perf/util/bpf_skel/lock_data.h
> +++ b/tools/perf/util/bpf_skel/lock_data.h
> @@ -76,4 +84,320 @@ struct slab_cache_data {

[ ... ]

> +static __always_inline struct task_struct *get_lock_owner(__u64 lock, __u32 flags)
> +{
> +	struct task_struct *task;
> +	__u64 owner = 0;
> +
> +	if (flags & LCB_F_MUTEX) {
> +		struct mutex *mutex = (void *)lock;
> +
> +		if (bpf_core_field_exists(mutex->owner.counter)) {
> +			owner = BPF_CORE_READ(mutex, owner.counter);
> +			if (owner & 0x4UL)
> +				return NULL;
> +		} else if (bpf_core_type_exists(struct rt_mutex_base)) {
> +			struct rt_mutex_base *rtm = (void *)lock;
> +
> +			owner = (__u64)BPF_CORE_READ(rtm, owner);
> +			return (void *)(owner & ~1UL);
> +		}
> +	} else if (flags == LCB_F_READ || flags == LCB_F_WRITE) {
> +		struct rw_semaphore___new *rwsem = (void *)lock;
> +
> +		if (flags == LCB_F_WRITE && bpf_core_field_exists(rwsem->count.counter)) {
> +			__u64 count = BPF_CORE_READ(rwsem, count.counter);
> +
> +			/* Must have RWSEM_WRITER_LOCKED (bit 0) set */
> +			if (!(count & 1UL))
> +				return NULL;
> +		}
> +	/*
> +	 * Support for the BPF_TYPE_MATCHES argument to the
> +	 * __builtin_preserve_type_info builtin was added at some point during
> +	 * development of clang 15 and it's what is needed for
> +	 * bpf_core_type_matches.
> +	 */
> +#if __has_builtin(__builtin_preserve_type_info) && __clang_major__ >= 15
> +		if (bpf_core_type_matches(struct rw_semaphore___old)) {
> +			struct rw_semaphore___old *old = (void *)lock;
> +
> +			owner = (unsigned long)BPF_CORE_READ(old, owner);
> +		} else if (bpf_core_type_matches(struct rw_semaphore___new)) {
> +			owner = BPF_CORE_READ(rwsem, owner.counter);
> +		}
> +#else
> +		/* assume new struct */
> +		if (bpf_core_field_exists(rwsem->owner.counter))
> +			owner = BPF_CORE_READ(rwsem, owner.counter);
> +#endif
> +		/* RWSEM_READER_OWNED is bit 0 of owner */
> +		if (flags == LCB_F_WRITE && (owner & 1UL))
> +			return NULL;

[Severity: Medium]
In tools/perf/util/bpf_skel/lock_contention.bpf.c, contention_begin() calls
get_lock_owner(pelem->lock, pelem->flags) for both owner stack tracing and
LOCK_AGGR_TASK owner PID attribution:

tools/perf/util/bpf_skel/lock_contention.bpf.c:contention_begin() {
	...
	task = get_lock_owner(pelem->lock, pelem->flags);
	if (!task)
		goto skip_owner;
	...
	if (lock_owner) {
		task = get_lock_owner(pelem->lock, pelem->flags);
	...
}

Here pelem->flags comes from trace_contention_begin() and represents the
contending waiter's mode (LCB_F_READ in rwsem_down_read_slowpath() or
LCB_F_WRITE in rwsem_down_write_slowpath()), rather than the lock owner's
mode.

When a writer contends on a reader-owned rw_semaphore, pelem->flags is
LCB_F_WRITE while rwsem->count does not have RWSEM_WRITER_LOCKED (bit 0) set
and rwsem->owner has RWSEM_READER_OWNED (bit 0) set. Conversely, when a
reader contends (flags == LCB_F_READ), both checks are bypassed.

Will checking flags == LCB_F_WRITE in get_lock_owner() cause it to always
return NULL whenever a writer contends on a reader-owned rw_semaphore,
dropping owner attribution and owner callstacks in perf lock contention -b -o?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017171437.2066343-1-irogers@google.com?part=1

  reply	other threads:[~2026-10-17 17:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  5:45 [PATCH v1 0/5] perf bpf-filter / lock contention: Add lock_held() sample filter and RCU/SRCU support Ian Rogers
2026-10-17  5:45 ` [PATCH v1 1/5] perf lock contention: Share common BPF and lock type definitions in lock_data.h Ian Rogers
2026-10-17  5:52   ` sashiko-bot
2026-10-17  5:45 ` [PATCH v1 2/5] perf bpf-filter: Add lock_held() sample filter Ian Rogers
2026-10-17  6:09   ` sashiko-bot
2026-10-17  5:45 ` [PATCH v1 3/5] perf test: Add tests for lock_held() BPF " Ian Rogers
2026-10-17  5:49   ` sashiko-bot
2026-10-17  5:45 ` [PATCH v1 4/5] perf bpf-filter: Extend lock_held() to support RCU, Tasks Trace RCU, and SRCU Ian Rogers
2026-10-17  5:56   ` sashiko-bot
2026-10-17  5:45 ` [PATCH v1 5/5] perf lock contention: Extend BPF lock contention to RCU " Ian Rogers
2026-10-17  6:08   ` sashiko-bot
2026-10-17 17:14 ` [PATCH v2 0/6] perf bpf-filter / lock contention: Add lock_held() sample filter and RCU/SRCU support Ian Rogers
2026-10-17 17:14   ` [PATCH v2 1/6] perf lock contention: Share common BPF and lock type definitions in lock_data.h Ian Rogers
2026-10-17 17:31     ` sashiko-bot [this message]
2026-10-17 17:14   ` [PATCH v2 2/6] perf bpf-filter: Add lock_held() sample filter Ian Rogers
2026-10-17 17:35     ` sashiko-bot
2026-10-17 17:14   ` [PATCH v2 3/6] perf test: Add tests for lock_held() BPF " Ian Rogers
2026-10-17 17:17     ` sashiko-bot
2026-10-17 17:14   ` [PATCH v2 4/6] perf bpf-filter: Extend lock_held() to support RCU, Tasks Trace RCU, and SRCU Ian Rogers
2026-10-17 17:25     ` sashiko-bot
2026-10-17 17:14   ` [PATCH v2 5/6] perf lock contention: Extend BPF lock contention to RCU " Ian Rogers
2026-10-17 17:30     ` sashiko-bot
2026-10-17 17:14   ` [PATCH v2 6/6] perf lock contention: Filter events before creating lock_stat Ian Rogers
2026-10-17 17:17     ` sashiko-bot
2026-10-18  5:37   ` [PATCH v3 0/6] perf bpf-filter / lock contention: Add lock_held() sample filter and RCU/SRCU support Ian Rogers
2026-10-18  5:37     ` [PATCH v3 1/6] perf lock contention: Share common BPF and lock type definitions in lock_data.h Ian Rogers
2026-10-18  5:50       ` sashiko-bot
2026-10-18  5:37     ` [PATCH v3 2/6] perf bpf-filter: Add lock_held() sample filter Ian Rogers
2026-10-18  6:12       ` sashiko-bot
2026-10-18  5:37     ` [PATCH v3 3/6] perf test: Add tests for lock_held() BPF " Ian Rogers
2026-10-18  5:41       ` sashiko-bot
2026-10-18  5:37     ` [PATCH v3 4/6] perf bpf-filter: Extend lock_held() to support RCU, Tasks Trace RCU, and SRCU Ian Rogers
2026-10-18  5:51       ` sashiko-bot
2026-10-18  5:37     ` [PATCH v3 5/6] perf lock contention: Extend BPF lock contention to RCU " Ian Rogers
2026-10-18  5:48       ` sashiko-bot
2026-10-18  5:37     ` [PATCH v3 6/6] perf lock contention: Filter events before creating lock_stat Ian Rogers
2026-10-18  5:40       ` sashiko-bot

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=sashiko-outbox-175709@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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