On Tue, 2014-04-22 at 06:23 +0200, Manfred Spraul wrote: > 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.
Ok, I was mixing 'issues' then. > 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. Right, but as I mentioned, this also contradicts the fact that shmmin cannot be 0. And again, I don't know who's correct here. Do any standards mention this? I haven't found anything, and hard-codding shmmin to 1 seems to be different among OSs, Linux choosing to do so. This difference must also be commented in the manpage. That said, I believe that violating this "feature" and forbidding disabling shm would probably have a more severe penalty (security, perhaps) for users who rely on this. So while I'm really annoyed that we "cannot" use 0 because of this, I'm going to give up arguing. I believe you approach is the safer way of going. Thanks a lot for looking into this, Manfred. Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
