linux-kernel - Re: [PATCH] ftrace based hard lockup detector

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]

Message-ID: <c62985530901190525j456f4f1ds6f610fd5241b2aa7@mail.gmail.com>
Date:	Mon, 19 Jan 2009 14:25:29 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ftrace based hard lockup detector

2009/1/19 Steven Rostedt <rostedt@...dmis.org>:
> Ah, OK, the check is in the function tracer. Hmm, my logdev code had an
> option to enable tracing at early bootup. Instead of using the normal
> memory alloction for the ring buffer, it needed to use alloc_bootmem. I
> wonder if it would be worth it to allow for a tracer to do the same if it
> needs to be allocated early on (before memory is initialized)?
>
> --Steve


Hi Steve,

Yeah I think that would be a good idea.


BTW, tote that for the moment, this hard lockup detector is basic, but
I could even make it relying
to the function graph tracer and then dump the whole stack of
functions called. I think that could
give a more precise backtrace.... (and more human readable).
--
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/