linux-kernel - Re: [PATCH] ipc,shm: increase default size for shmmax

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: <20140416154631.6d0173498c60619d454ae651@linux-foundation.org>
Date:	Wed, 16 Apr 2014 15:46:31 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	Davidlohr Bueso <davidlohr@...com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>, aswin@...com,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] ipc,shm: increase default size for shmmax

On Sun, 13 Apr 2014 20:05:34 +0200 Manfred Spraul <manfred@...orfullife.com> wrote:

> Hi Andrew,
> 
> On 04/02/2014 12:08 AM, Andrew Morton wrote:
> > Well, I'm assuming 64GB==infinity. It *was* infinity in the RHEL5 
> > timeframe, but infinity has since become larger so pickanumber. 
> 
> I think infinity is the right solution:
> The only common case where infinity is wrong would be Android - and 
> Android disables sysv shm entirely.
> 
> There are two patches:
> http://marc.info/?l=linux-kernel&m=139730332306185&q=raw
> http://marc.info/?l=linux-kernel&m=139727299800644&q=raw
> 
> Could you apply one of them?
> I wrote the first one, thus I'm biased which one is better.

I like your patch because applying it might encourage you to send more
kernel patches - I miss the old days ;)

But I do worry about disrupting existing systems so I like Davidlohr's
idea of making the change a no-op for people who are currently
explicitly setting shmmax and shmall.

In an ideal world, system administrators would review this change,
would remove their explicit limit-setting and would retest everything
then roll it out.  But in the real world with Davidlohr's patch, they
just won't know that we did this and they'll still be manually
configuring shmmax/shmall ten years from now.  I almost wonder if we
should drop a printk_once("hey, you don't need to do that any more")
when shmmax/shmall are altered?

I think the changelogs for both patches could afford to spend much more
time talking about *why* we're making this change.  What problem is
the current code causing?  This is a somewhat risky change and we
should demonstrate good reasons for making it.  If people end up taking
damage because of this change, they are going to be looking at that
changelog trying to work out why we did this to them, so let's explain
it carefully.

--
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/