linux-kernel - Re: [PATCH] printk: inject caller information into the body of message

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]

Message-ID: <20181008154317.2owdxq7y6kie5sxh@pathway.suse.cz>
Date:   Mon, 8 Oct 2018 17:43:17 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitriy Vyukov <dvyukov@...gle.com>,
        kbuild test robot <fengguang.wu@...el.com>,
        syzkaller <syzkaller@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] printk: inject caller information into the body of
 message

On Tue 2018-10-02 15:38:51, Sergey Senozhatsky wrote:
> On (10/01/18 20:21), Tetsuo Handa wrote:
> > Maybe "struct printk_buffer" after all becomes identical to "struct cont". But
> > I guess that even 16 printk_buffer-s is practically sufficient for 1024 CPUs
> > system, and allocating NR_CPUS printk_buffer-s will be too wasteful.
> 
> NR_CPUS buffers is quite a lot, indeed. Maybe we can do something like
> NR_CPUS/4 + 1, etc. Kconfig option will be super hard to get right for
> distributions. If people who wrote the code didn't agree on the correct
> number of buffers and passed it to the distributions, then it's a good
> sign than distributions will have problems picking up the good number as
> well.

I am afraid that only some testing or real life experience might tell
us what number is good enough.

The good thing is that it could only be better than the current
state when we have only one cont buffer.

Also I would not be so much afraid of the per-cpu buffer. We already
use 16kB per-CPU for printk_safe and printk_nmi. One more kB should
no be that big deal.

Best Regards,
Petr