On Fri,  8 Mar 2019 11:32:04 -0800
Douglas Anderson <diand...@chromium.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.ga21...@google.com
> 
> Reported-by: Brian Norris <briannor...@chromium.org>
> Signed-off-by: Douglas Anderson <diand...@chromium.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


_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Reply via email to