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? > > The change itself is trivial, the only problem are interger overflows. > The overflows are not new, but if we make huge values the default, > then the code should be free from overflows. > > SHMMAX: > > - shmmem_file_setup places a hard limit on the segment size: > MAX_LFS_FILESIZE. > > On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are > possible. Rounded up to full pages the actual allocated size > is 0. --> must be fixed, patch 3 > > - shmat: > - find_vma_intersection does not handle overflows properly. > --> must be fixed, patch 1 > > - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE > and checks for overflows (i.e.: map 2 GB, starting from > addr=2.5GB fails). > > SHMALL: > - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and > returns 0. --> must be fixed, patch 2. > > User space: > - Obviuosly, there could be overflows in user space. There is nothing > we can do, only use values smaller than ULONG_MAX. > I ended with "ULONG_MAX - 1L<<24": > > - TASK_SIZE cannot be used because it is the size of the current > task. Could be 4G if it's a 32-bit task on a 64-bit kernel. > > - The maximum size is not standardized across archs: > I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. > > - Just in case some arch revives a 4G/4G split, nearly > ULONG_MAX is a valid segment size. > > - 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. I do agree with the series iff we endup taking this 'increase the limit size approach'. But I just don't see the need. Thanks, 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/
