[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b725c54e-a5b7-12fe-8269-8beccc4c88ce@i-love.sakura.ne.jp>
Date: Tue, 6 Nov 2018 18:56:03 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Petr Mladek <pmladek@...e.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Dmitriy Vyukov <dvyukov@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Alexander Potapenko <glider@...gle.com>,
Fengguang Wu <fengguang.wu@...el.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
Ingo Molnar <mingo@...hat.com>,
Will Deacon <will.deacon@....com>
Subject: Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep
messages.
On 2018/11/06 17:38, Petr Mladek wrote:
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
1 lock held by swapper/1/0:
#0:
(
rcu_read_lock
){....}
, at: trace_call_bpf+0xf8/0x640 kernel/trace/bpf_trace.c:46
is not welcomed and
1 lock held by swapper/1/0:
#0: (rcu_read_lock){....}, at: trace_call_bpf+0xf8/0x640 kernel/trace/bpf_trace.c:46
is welcomed.
If you want to avoid fallback to direct printk(), please allocate on-stack
buffer with appropriate size. Since lockdep splat may happen when kernel
stack is already tight, blindly allocating large buffer on the stack is
not good.
Powered by blists - more mailing lists