linux-kernel - Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

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:   Tue, 6 Nov 2018 09:38:56 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        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 Fri 2018-11-02 14:36:29, Peter Zijlstra wrote:
> On Fri, Nov 02, 2018 at 10:31:57PM +0900, Tetsuo Handa wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> > 
> >   RCU used illegally from idle CPU!
> >   rcu_scheduler_active = 2, debug_locks = 1
> >   RSP: 0018:ffffffff88007bb8 EFLAGS: 00000286
> >   RCU used illegally from extended quiescent state!
> >    ORIG_RAX: ffffffffffffff13
> >   1 lock held by swapper/1/0:
> >   RAX: dffffc0000000000 RBX: 1ffffffff1000f7b RCX: 0000000000000000
> >    #0: 
> >   RDX: 1ffffffff10237b8 RSI: 0000000000000001 RDI: ffffffff8811bdc0
> >   000000004b34587c
> >   RBP: ffffffff88007bb8 R08: ffffffff88075e00 R09: 0000000000000000
> >    (
> >   R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> >   rcu_read_lock
> >   R13: ffffffff88007c78 R14: 0000000000000000 R15: 0000000000000000
> >   ){....}
> >    arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
> >    default_idle+0xc2/0x410 arch/x86/kernel/process.c:498
> >   , at: trace_call_bpf+0xf8/0x640 kernel/trace/bpf_trace.c:46
> 
> WTH is that buffered aPI, and no, that breaks my earlyprintk stuff.

The API is supposed to replace the existing unreliable and tricky code,
see struct cont and KERN_CONT flag in kernel/printk/printk.c.

The solution has been discussed many times. The preferred solution
is to use explicit buffers instead of having many
per-cpu/per-context ones and auto magically switching between them.

The original idea was to use buffers on stack. But the stack is
limited and people would need to guess the length.

This current approach uses small pool of buffers and simple logic
to get/put one. If any buffer is not available, it falls back
to direct printk(), see
https://lkml.kernel.org/r/1541165517-3557-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp

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().

Best Regards,
Petr