| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <3461a0dc-b163-31ed-a96e-f503ade74260@arm.com>
Date: Mon, 11 Mar 2024 15:58:18 +0000
From: James Clark <james.clark@....com>
To: Ben Gainey <ben.gainey@....com>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
namhyung@...nel.org, irogers@...gle.com, adrian.hunter@...el.com
Subject: Re: [PATCH v2 1/4] perf: Support PERF_SAMPLE_READ with inherit_stat
On 08/02/2024 13:10, Ben Gainey wrote:
> This change allows events to use PERF_SAMPLE READ with inherit
> so long as both inherit_stat and PERF_SAMPLE_TID are set.
I saw there was a discussion on V1 about adding a new flag because this
is an ABI break. Personally I'm not sure if it is required given that it
wasn't allowed before, so there wouldn't be any users to experience it.
I suppose there _could_ be a new user if they stumbled across this now,
but it's not like they would see that as a regression because it wasn't
allowed before anyway. Maybe it's cleaner to just use the existing flags
rather than adding a new one.
Perf even guarded the condition in userspace as far as I can see, so
nobody using Perf would hit this either.
>
> In this configuration, and event will be inherited into any
and -> any/an?
> child processes / threads, allowing convenient profiling of a
> multiprocess or multithreaded application, whilst allowing
> profiling tools to collect per-thread samples, in particular
> of groups of counters.
>
> Signed-off-by: Ben Gainey <ben.gainey@....com>
> ---
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 53 ++++++++++++++++++++++++++------------
> 2 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index d2a15c0c6f8a..7d405dff6694 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -932,6 +932,7 @@ struct perf_event_context {
>
> int nr_task_data;
> int nr_stat;
> + int nr_stat_read;
> int nr_freq;
> int rotate_disable;
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index f0f0f71213a1..dac7093b3608 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1795,8 +1795,11 @@ list_add_event(struct perf_event *event, struct perf_event_context *ctx)
> ctx->nr_events++;
> if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
> ctx->nr_user++;
> - if (event->attr.inherit_stat)
> + if (event->attr.inherit_stat) {
> ctx->nr_stat++;
> + if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))
> + ctx->nr_stat_read++;
> + }
>
> if (event->state > PERF_EVENT_STATE_OFF)
> perf_cgroup_event_enable(event, ctx);
> @@ -2019,8 +2022,11 @@ list_del_event(struct perf_event *event, struct perf_event_context *ctx)
> ctx->nr_events--;
> if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
> ctx->nr_user--;
> - if (event->attr.inherit_stat)
> + if (event->attr.inherit_stat) {
> ctx->nr_stat--;
> + if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))
This condition is repeated a few times, maybe we could add a macro like
"has_sample_read_thread()" or something or whatever we're calling it
exactly.
It might have prevented the mistake in copying the condition below in
perf_event_count()...
> + ctx->nr_stat_read--;
> + }
>
> list_del_rcu(&event->event_entry);
>
> @@ -3529,11 +3535,17 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
> perf_ctx_disable(ctx, false);
>
> /* PMIs are disabled; ctx->nr_pending is stable. */
> - if (local_read(&ctx->nr_pending) ||
> + if (ctx->nr_stat_read ||
> + next_ctx->nr_stat_read ||
> + local_read(&ctx->nr_pending) ||
> local_read(&next_ctx->nr_pending)) {
> /*
> * Must not swap out ctx when there's pending
> * events that rely on the ctx->task relation.
> + *
> + * Likewise, when a context contains inherit+inherit_stat+SAMPLE_READ
> + * events they should be switched out using the slow path
> + * so that they are treated as if they were distinct contexts.
> */
> raw_spin_unlock(&next_ctx->lock);
> rcu_read_unlock();
> @@ -3545,6 +3557,7 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
>
> perf_ctx_sched_task_cb(ctx, false);
> perf_event_swap_task_ctx_data(ctx, next_ctx);
> + perf_event_sync_stat(ctx, next_ctx);
>
> perf_ctx_enable(ctx, false);
>
> @@ -3559,8 +3572,6 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
> RCU_INIT_POINTER(next->perf_event_ctxp, ctx);
>
> do_switch = 0;
> -
> - perf_event_sync_stat(ctx, next_ctx);
The commit message gives a very high level summary of the user visible
changes, but it doesn't say what changes have been made to the code to
accomplish it.
I wasn't sure what this move of perf_even_sync_stat() is for, because
it's actually skipped over when nr_stat_read != 0, which is in this new
case?
> }
> raw_spin_unlock(&next_ctx->lock);
> raw_spin_unlock(&ctx->lock);
> @@ -4533,8 +4544,13 @@ static void __perf_event_read(void *info)
> raw_spin_unlock(&ctx->lock);
> }
>
> -static inline u64 perf_event_count(struct perf_event *event)
> +static inline u64 perf_event_count(struct perf_event *event, bool from_sample)
There are only two trues, and 7 existing falses, so you could just add a
new function like perf_event_count_sample(). But I suppose that's a
style thing.
> {
> + if (from_sample && event->attr.inherit &&
> + event->attr.inherit &&
> + (event->attr.sample_type & PERF_SAMPLE_TID)) {
There's something suspicious about this condition with the
event->attr.inherit twice. Should it be && inherit_stat? I don't know if
there's any test that could have caught this, if it's affecting the
existing inherit but not inherit_stat case?
And it's also probably not very helpful at this stage, but if you run
checkpatch.pl on your patches it will point out some of the style issues.
Powered by blists - more mailing lists