linux-kernel - Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending on the number of CPUs

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:	Thu, 26 Jun 2014 16:32:15 -0700
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	hpa@...ux.intel.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Lunn <andrew@...n.ch>,
	Stephen Warren <swarren@...dotorg.org>,
	Michal Hocko <mhocko@...e.cz>, Petr Mladek <pmladek@...e.cz>,
	Joe Perches <joe@...ches.com>,
	Arun KS <arunks.linux@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Davidlohr Bueso <davidlohr@...com>,
	Chris Metcalf <cmetcalf@...era.com>
Subject: Re: [PATCH v8 4/4] printk: allow increasing the ring buffer depending
 on the number of CPUs

On Thu, Jun 26, 2014 at 4:20 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Fri, 27 Jun 2014 01:16:30 +0200 "Luis R. Rodriguez" <mcgrof@...e.com> wrote:
>
>> > > Another note --  since this option depends on SMP and !BASE_SMALL technically
>> > > num_possible_cpus() won't ever return something smaller than or equal to 1
>> > > but because of the default values chosen the -1 on the compuation does affect
>> > > whether or not this will trigger on > 64 CPUs or >= 64 CPUs, keeping the
>> > > -1 means we require > 64 CPUs.
>> >
>> > hm, that sounds like more complexity.
>> >
>> > > This all can be changed however we like but the language and explained logic
>> > > would just need to be changed.
>> >
>> > Let's start out simple.  What's wrong with doing
>> >
>> >     log buf len = max(__LOG_BUF_LEN, nr_possible_cpus * per-cpu log buf len)
>>
>> Sure, you already took in the patch series though so how would you like to
>> handle a respin, you just drop the last patch and we respin it?
>
> A fresh patch would suit.  That's if you think it is a reasonable
> approach - you've thought about this stuff more than I have!

The way its implemented now makes more technical sense, in short it
assumes the first boot (and CPU) gets the full default kernel ring
buffer size, the extra size is for the gibberish that each extra CPU
is expected to spew out in the worst case. What you propose makes the
explanation simpler and easier to understand but sends the wrong
message about exactly how the growth of the kernel ring buffer is
expected scale with the addition of more CPUs.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/