linux-kernel - Re: [PATCH v2 1/2] tracing: kdb: Fix ftdump to not sleep

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, 8 Mar 2019 15:19:54 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Jason Wessel <jason.wessel@...driver.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        kgdb-bugreport@...ts.sourceforge.net,
        Brian Norris <briannorris@...omium.org>,
        Vasyl Gomonovych <gomonovych@...il.com>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        linux-kernel@...r.kernel.org, Baohong Liu <baohong.liu@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH v2 1/2] tracing: kdb: Fix ftdump to not sleep

On Fri,  8 Mar 2019 11:32:04 -0800
Douglas Anderson <dianders@...omium.org> wrote:

> As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
> BUG for "sleeping function called from invalid context".
> 
> kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
> atomic context.  A very simple solution for this is to add allocation
> flags to ring_buffer_read_prepare() so kdb can call it without
> triggering the allocation error.  This patch does that.
> 
> Note that in the original email thread about this, it was suggested
> that perhaps the solution for kdb was to either preallocate the buffer
> ahead of time or create our own iterator.  I'm hoping that this
> alternative of adding allocation flags to ring_buffer_read_prepare()
> can be considered since it means I don't need to duplicate more of the
> core trace code into "trace_kdb.c" (for either creating my own
> iterator or re-preparing a ring allocator whose memory was already
> allocated).
> 
> NOTE: another option for kdb is to actually figure out how to make it
> reuse the existing ftrace_dump() function and totally eliminate the
> duplication.  This sounds very appealing and actually works (the "sr
> z" command can be seen to properly dump the ftrace buffer).  The
> downside here is that ftrace_dump() fully consumes the trace buffer.
> Unless that is changed I'd rather not use it because it means "ftdump
> | grep xyz" won't be very useful to search the ftrace buffer since it
> will throw away the whole trace on the first grep.  A future patch to
> dump only the last few lines of the buffer will also be hard to
> implement.
> 
> [1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
> 
> Reported-by: Brian Norris <briannorris@...omium.org>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
> 

Thanks for sending this. I'm currently traveling and also have to get
the merge window patches out, I wont be able to get to these till I
have that settled. If you don't hear from me in a week, please send me
a reminder.

Thanks!

-- Steve