linux-kernel - Re: [PATCH] perf_counter: Always return the parent counter id to userspace

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1248087346.15751.8437.camel@twins>
Date:	Mon, 20 Jul 2009 12:55:46 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Anton Blanchard <anton@...ba.org>
Cc:	mingo@...e.hu, paulus@...ba.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf_counter: Always return the parent counter id to
 userspace

On Mon, 2009-07-20 at 20:38 +1000, Anton Blanchard wrote:
> When inheriting counters new tasks get new counter ids. Since
> userspace only knows about the parent ids we need to return them
> and not the actual ids.
> 
> Signed-off-by: Anton Blanchard <anton@...ba.org>

Please add -p to your diff args, or use
QUILT_DIFF_OPTS="--show-c-function".


> ---
> Index: linux.trees.git/kernel/perf_counter.c
> ===================================================================
> --- linux.trees.git.orig/kernel/perf_counter.c	2009-07-20 20:17:44.000000000 +1000
> +++ linux.trees.git/kernel/perf_counter.c	2009-07-20 20:36:13.000000000 +1000
> @@ -154,6 +154,20 @@
>  	}
>  }
>  
> +/* 
> + * If we inherit counters we want to return the parent counter id 
> + * to userspace.
> + */
> +static u64 primary_counter_id(struct perf_counter *counter)
> +{
> +	u64 id = counter->id;
> +
> +	if (counter->parent)
> +		id = counter->parent->id;
> +
> +	return id;
> +}
> +
>  /*
>   * Get the perf_counter_context for a task and lock it.
>   * This has to cope with with the fact that until it is locked,
> @@ -1705,7 +1719,7 @@
>  		values[n++] = counter->total_time_running +
>  			atomic64_read(&counter->child_total_time_running);
>  	if (counter->attr.read_format & PERF_FORMAT_ID)
> -		values[n++] = counter->id;
> +		values[n++] = primary_counter_id(counter);
>  	mutex_unlock(&counter->child_mutex);
>  
>  	if (count < n * sizeof(u64))

Its impossible to read() anything but the parent counter, right?

Hmm, maybe because the lazy context switch thing allows counters to
wander about?

> @@ -2548,7 +2562,7 @@
>  		lost_event.header.type = PERF_EVENT_LOST;
>  		lost_event.header.misc = 0;
>  		lost_event.header.size = sizeof(lost_event);
> -		lost_event.id          = counter->id;
> +		lost_event.id          = primary_counter_id(counter);
>  		lost_event.lost        = atomic_xchg(&data->lost, 0);
>  
>  		perf_output_put(handle, lost_event);

All output is already done to the parent counter:

perf_output_begin():
	/*
	 * For inherited counters we send all the output towards the parent.
	 */
	if (counter->parent)
		counter = counter->parent;

> @@ -2704,8 +2718,10 @@
>  	if (sample_type & PERF_SAMPLE_ADDR)
>  		perf_output_put(&handle, data->addr);
>  
> -	if (sample_type & PERF_SAMPLE_ID)
> -		perf_output_put(&handle, counter->id);
> +	if (sample_type & PERF_SAMPLE_ID) {
> +		u64 id = primary_counter_id(counter);
> +		perf_output_put(&handle, id);
> +	}
>  
>  	if (sample_type & PERF_SAMPLE_CPU)
>  		perf_output_put(&handle, cpu_entry);

This will actually wreck things.

It would be impossible to relate PERF_EVENT_PERIOD/THROTTLE (and maybe
others) to their respective counters.

If you have inherited counters and each task will have separate ones,
you need separate IDs in their sample stream to be able to related
PERIOD and THROTTLE events.

> @@ -2727,7 +2743,7 @@
>  			if (sub != counter)
>  				sub->pmu->read(sub);
>  
> -			group_entry.id = sub->id;
> +			group_entry.id = primary_counter_id(sub);
>  			group_entry.counter = atomic64_read(&sub->count);
>  
>  			perf_output_put(&handle, group_entry);

Right, this I think you're right about.

> @@ -2790,11 +2806,7 @@
>  		u64 id;
>  
>  		event.header.size += sizeof(u64);
> -		if (counter->parent)
> -			id = counter->parent->id;
> -		else
> -			id = counter->id;
> -
> +		id = primary_counter_id(counter);
>  		event.format[i++] = id;
>  	}

Indeed, when there are multiple cases, the new function makes sense.

> @@ -3209,7 +3221,7 @@
>  			.size = sizeof(event),
>  		},
>  		.time = sched_clock(),
> -		.id = counter->id,
> +		.id = primary_counter_id(counter),
>  		.period = period,
>  	};
>  

I'm assuming this is in perf_log_period(), for which, see the above
comment.

> @@ -3241,7 +3253,7 @@
>  			.size = sizeof(throttle_event),
>  		},
>  		.time	= sched_clock(),
> -		.id	= counter->id,
> +		.id	= primary_counter_id(counter),
>  	};
>  
>  	ret = perf_output_begin(&handle, counter, sizeof(throttle_event), 1, 0);

>>From the context this appears to be perf_log_throttle(), again see the
above comment.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/