Hi all,
the increase of SHMMAX/SHMALL is now a 4 patch series, and still
not ready for merging (see at the end, TASK_SIZE and s390).
If we increase the default limits for SHMMAX and SHMALL,
integer overflows could happen:
SHMMAX:
- shmmem_file_setup places a hard limit on the segment size:
MAX_LFS_FILESIZE.
on 32-bit, the limit is > 1 TB.
--> 32-bit: 4 GB-1 segments are possible.
Rounded up to full pages the actual allocated size
is 0.
--> patch 3
on 64-bit, this is 0x7fff ffff ffff ffff
--> no chance for an overflow.
- shmat:
- find_vma_intersection does not handle overflows properly
--> patch 1.
- do_mmap_pgoff limits mappings to TASK_SIZE
3 GB on 32-bit (assuming x86)
47 bits on 64-bit (assuming x86)
- do_mmap_pgoff checks for overflows:
map 2 GB, starting from addr=2.5GB fails.
SHMALL:
- after creating 8192 segments size (1L<<63)-1, shm_tot
overflows and returns 0.
--> patch 2.
And finally:
Patch 4, increase the limits to ULONG_MAX
Open points:
- Better ideas to handle uapi: Is it worth the effort to get
access to TASK_SIZE? I would say no.
- Better ideas with regards to SHMALL? The values are probably
large enough, but still arbitrary.
- The TASK_SIZE definition for e.g. S390 differs: It's not
a constant, instead it is the current task size for current.
And it seems that the task size can change based on
(virtual) memory pressure (s390_mmap_check()).
For new namespaces, this might have interesting effects, i.e.
this must be fixed.
--
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>