linux-kernel - Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function

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:	Fri, 12 Jul 2013 15:20:58 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Frederic Weisbecker <fweisbec@...il.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel: trace: remove __init from race_selftest_startup_function()
 and trace_selftest_startup_function_graph()

On 07/12/2013 11:04 AM, Chen Gang wrote:
> On 07/12/2013 10:38 AM, Steven Rostedt wrote:
>> On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
>>> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
>>>> On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>>>>
>>>>>> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
>>>>>> use '__init', so not waste memory keeping them around ?
>>>> Yeah, they should all be set to __init, but that's pretty low on the
>>>> totem poll, as distros don't enable selftests in their main kernels.
>>>
>>> Excuse me, my English is not quite well, I guess your meaning is:
>>>
>>>   they should all be set to '__init', although it is minor in real world.
>>>
>>> Is it correct ?
>>
>> Correct.
>>
>>>
>>>
>>> For me, I recommend to let all *selftest* as the same: "all add '
>>> __init' or none add '__init'" (if choose add, all report warnings).
>>>
>>> Is it suitable to still send new related patch for it ? If so, could
>>> you provide your suggesting choice (all add, or none add) ?
>>
>> Does this patch fix your warning?
>>
>> -- Steve
>>
> 

After the test, they will not report the related warning.

Hmm..., but that will let another none *selftest* functions miss
'__read_mostly'.

Do the original *selftest* intend to have no '__init' so can fit other
none *selftest* with '__read_mostly', and without warnings ?

Welcome any members' suggestions or completions.

Thanks.

> I guess it can (although I do not give a compiling test), it seems a
> better fixing.
> 
> And is it suitable to let all *selftest* as the same ? (all add, or none
> add '__init').
> 
> Thanks.
> 
>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
>> index a4ed382..5e794d1 100644
>> --- a/kernel/trace/trace.h
>> +++ b/kernel/trace/trace.h
>> @@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct tracer *trace,
>>  					       struct trace_array *tr);
>>  extern int trace_selftest_startup_branch(struct tracer *trace,
>>  					 struct trace_array *tr);
>> +/*
>> + * Tracer data references selftest functions that only occur
>> + * on boot up. These can be __init functions. Thus, when selftests
>> + * are enabled, then the tracers need to reference __init functions.
>> + */
>> +#define __tracer_data		__refdata
>> +#else
>> +/* Tracers are seldom changed. Optimize when selftests are disabled. */
>> +#define __tracer_data		__read_mostly
>>  #endif /* CONFIG_FTRACE_STARTUP_TEST */
>>  
>>  extern void *head_page(struct trace_array_cpu *data);
>> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
>> index b863f93..38fe148 100644
>> --- a/kernel/trace/trace_functions.c
>> +++ b/kernel/trace/trace_functions.c
>> @@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
>>  	return 0;
>>  }
>>  
>> -static struct tracer function_trace __read_mostly =
>> +static struct tracer function_trace __tracer_data =
>>  {
>>  	.name		= "function",
>>  	.init		= function_trace_init,
>>
>>
>>
>>
> 
> 


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