linux-kernel - Re: [PATCH 2/7] perf/cgroup: order events in RB tree by cgroup id

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]

Date:   Mon, 8 Jul 2019 18:21:15 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Ian Rogers <irogers@...gle.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org,
        Kan Liang <kan.liang@...ux.intel.com>,
        Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 2/7] perf/cgroup: order events in RB tree by cgroup id

On Mon, Jul 01, 2019 at 11:59:50PM -0700, Ian Rogers wrote:
> +#ifndef CONFIG_CGROUP_PERF
> +	/*
> +	 * Without cgroups, with a task context, iterate over per-CPU and any
> +	 * CPU events.
> +	 */
> +	const int max_itrs = 2;
> +#else
> +	/*
> +	 * The depth of cgroups is limited by MAX_PATH. It is unlikely that this
> +	 * many parent-child related cgroups will have perf events
> +	 * monitored. Limit the number of cgroup iterators to 16.
> +	 */
> +	const int max_cgroups_with_events_depth = 16;
> +	/*
> +	 * With cgroups we either iterate for a task context (per-CPU or any CPU
> +	 * events) or for per CPU the global and per cgroup events.
> +	 */
> +	const int max_itrs = max(2, 1 + max_cgroups_with_events_depth);

That seems like a very complicated way to write 17.

> +#endif
> +	/* The number of iterators in use. */
> +	int num_itrs;
> +	/*
> +	 * A set of iterators, the iterator for the visit is chosen by the
> +	 * group_index.
> +	 */
> +	struct perf_event *itrs[max_itrs];

And that is 136 bytes of stack. Which I suppose is just about
acceptible.

But why not something like:

	struct perf_event *iters[IS_ENABLED(CONFIG_CGROUP_PERF) ? 17 : 2];

	iters[i++] = foo;
	WARN_ON_ONCE(i >= ARRAY_SIZE(iters));

?