On Tue, 08 Sep 2015 10:17:15 -0400
Sasha Levin wrote:
> Yes, I agree that it would be nicer if we init it rather than ignore it,
> but I wanted to avoid trying to do an extra allocation on this path since
> it usually happens when the system oopsed, so allocations might be reliable
> and we want
On 09/08/2015 10:13 AM, Steven Rostedt wrote:
> On Sun, 06 Sep 2015 10:29:43 -0400
> Sasha Levin wrote:
>
>
>>> So it is safe to call the function cpumask_test_cpu without doing
>>> checking.
>>
>> Can you point me to exactly where trace_init_global_iter() initializes
>> iter->started?
>
> Woul
On Sun, 06 Sep 2015 10:29:43 -0400
Sasha Levin wrote:
> > So it is safe to call the function cpumask_test_cpu without doing
> > checking.
>
> Can you point me to exactly where trace_init_global_iter() initializes
> iter->started?
Wouldn't the better solution be to initialize it in that functio
On 09/06/2015 05:20 AM, Minfei Huang wrote:
> On 09/04/15 at 12:45pm, Sasha Levin wrote:
>> > We don't init iter->started when dumping the ftrace buffer, and there's no
>> > real need to do so - so allow skipping that check if the iter doesn't have
>> > an initialized ->started cpumask.
>> >
>> >
On 09/04/15 at 12:45pm, Sasha Levin wrote:
> We don't init iter->started when dumping the ftrace buffer, and there's no
> real need to do so - so allow skipping that check if the iter doesn't have
> an initialized ->started cpumask.
>
> Signed-off-by: Sasha Levin
> ---
> kernel/trace/trace.c |
We don't init iter->started when dumping the ftrace buffer, and there's no
real need to do so - so allow skipping that check if the iter doesn't have
an initialized ->started cpumask.
Signed-off-by: Sasha Levin
---
kernel/trace/trace.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-
6 matches
Mail list logo
