linux-kernel - Re: [RFC PATCH 0/2] tracing: Teach FETCH_MTD

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:	Thu, 28 Nov 2013 11:55:38 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Namhyung Kim <namhyung.kim@....com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...hat.com>,
	linux-kernel@...r.kernel.org, Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [RFC PATCH 0/2] tracing: Teach FETCH_MTD_symbol to handle per-cpu
 data

(2013/11/28 2:41), Oleg Nesterov wrote:
> On 11/27, Masami Hiramatsu wrote:
>>
>> (2013/11/27 2:43), Oleg Nesterov wrote:
>>>
>>> This doesn't allow to read the data from other CPUs, but at least
>>> the changes are simple and this_cpu_ is better than the reading
>>> from the obviously wrong address.
>>
>> Yeah, usually per_cpu variable is used in current cpu context.
>>
>>>> For the dynamic allocated per-cpu things, it is also good to give
>>>> a straight operation, like +10(percpu(%rdi)).
>>>
>>> Probably yes, but this needs more changes and I am still not sure
>>> this is really useful. And if we do this, we probably also need
>>> to allow to read from other CPUs...
>>
>> No, it is enough to provide "percpu(FETCHARG)" which just returns
>> current cpu's percpu variable address.
> 
> I don't really agree. I am not saying this is terribly useful, but:
> 
>> (Note that kprobes handler
>> runs in interrupt)
> 
> but this doesn't matter at all, I think. The code can execute, say,
> __percpu_counter_sum-like code.
>
> And even if we dump the .data..percpu memory (@percpu_symbol) the
> user might want to know the "global" state of this per-cpu object.

I see, but it is the problem solved in the next step.
IMHO, giving people to access just to this cpu's variable is enough
useful. Expanding it to other cpu is another one.

> And note that sometimes DEFINE_PER_CPU doesn't really connect to
> smp_processor_id(). Just for example, bp_cpuinfo[]. It is never
> used as this-cpu-data. This means that @bp_cpuinfo+whatever is
> always pointless.

Yeah, there should be some exceptions.

> But anyway I agree, this is not that important, lets ignore.

 :)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
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/