linux-kernel - Re: [PATCH] ftrace: allow dumping traces without tracking trace started cpus

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: <55EEEDEB.3080508@oracle.com>
Date:	Tue, 08 Sep 2015 10:17:15 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Minfei Huang <mhuang@...hat.com>, mingo@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ftrace: allow dumping traces without tracking trace started
 cpus

On 09/08/2015 10:13 AM, Steven Rostedt wrote:
> On Sun, 06 Sep 2015 10:29:43 -0400
> Sasha Levin <sasha.levin@...cle.com> 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 function,
> instead of checking if it is NULL? I think that's the true fix.
> "started" should not be ignored.

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 to get the ftrace buffer out as reliably as we can.


Thanks,
Sasha

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