[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5355EEC2.4010304@colorfullife.com>
Date: Tue, 22 Apr 2014 06:23:30 +0200
From: Manfred Spraul <manfred@...orfullife.com>
To: Davidlohr Bueso <davidlohr@...com>
CC: Davidlohr Bueso <davidlohr.bueso@...com>,
Michael Kerrisk <mtk.manpages@...il.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
gthelen@...gle.com, aswin@...com, linux-mm@...ck.org
Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL
On 04/21/2014 07:25 PM, Davidlohr Bueso wrote:
> On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote:
>> Hi all,
>>
>> the increase of SHMMAX/SHMALL is now a 4 patch series.
>> I don't have ideas how to improve it further.
> Manfred, is there any difference between this set and the one you sent a
> couple of days ago?
a) I updated the comments.
b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24)
>> - Using "0" as a magic value for infinity is even worse, because
>> right now 0 means 0, i.e. fail all allocations.
> Sorry but I don't quite get this. Using 0 eliminates the need for all
> these patches, no? I mean overflows have existed since forever, and
> taking this route would naturally solve the problem. 0 allocations are a
> no no anyways.
No. The patches are required to handle e.g. shmget(,ULONG_MAX,):
Right now, shmget(,ULONG_MAX,) results in a 0-byte segment.
The risk of using 0 is that it reverses the current behavior:
Up to now,
# sysctl kernel.shmall=0
disables allocations.
If we define 0 a infinity, then the same configuration would allow
unlimited allocations.
--
Manfred
--
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/
Powered by blists - more mailing lists