linux-kernel - Re: [PATCH v6] Unified trace buffer

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: <48DD8263.8020205@sgi.com>
Date:	Fri, 26 Sep 2008 17:46:27 -0700
From:	Mike Travis <travis@....com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Martin Bligh <mbligh@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCH v6] Unified trace buffer

Steven Rostedt wrote:
> On Fri, 26 Sep 2008, Mike Travis wrote:
>> Steven Rostedt wrote:
>>>> The other thing to consider is using a percpu variable.
>>> This structure is allocated on request.
>>>
>>> -- Steve
>>
>> Ahh, then it would need the yet to be added cpu_alloc() from Christoph.
> 
> We can always change this later.
> 
>> Your best bet then is to allocate based on nr_cpu_ids.
> 
> Actually in this case I chose num_possible_cpus(). Reason being is that 
> later I may add an interface to allow the user to select which CPUs they 
> want to trace, and this will only allocate a subset of CPU buffers. 
> (not going to implement that in the first release).
> 
> But to lay the ground work, I set a buffers->cpumask to be that of all the 
> cpus with buffers allocated. For now that mask is set to cpu_possible_map. 
> Since num_possible_cpus() is defined as cpus_weight_nr(cpu_possible_map) 
> I figured that was the better choice.
> 
> -- Steve

One problem though, it's *theoretically* possible for num_possible to be
less than nr_cpu_ids and a cpu index may extend past the end of your
allocated array.  This would happen if  the cpu indices are allocated
some other way than as each cpu is discovered.  For example, a system
might want a group of cpus in one section (say by node, or socket) and
then a hole in the cpu_possible_map until the next group.  nr_cpu_ids
is guaranteed to be the highest possible cpu + 1.

Cheers,
Mike
--
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/