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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ