On Sat 03-10-20 00:44:09, Topi Miettinen wrote: > On 2.10.2020 20.52, David Hildenbrand wrote: > > On 02.10.20 19:19, Topi Miettinen wrote: > > > The brk() system call allows to change data segment size (heap). This > > > is mainly used by glibc for memory allocation, but it can use mmap() > > > and that results in more randomized memory mappings since the heap is > > > always located at fixed offset to program while mmap()ed memory is > > > randomized. > > > > Want to take more Unix out of Linux? > > > > Honestly, why care about disabling? User space can happily use mmap() if > > it prefers. > > brk() interface doesn't seem to be used much and glibc is happy to switch to > mmap() if brk() fails, so why not allow disabling it optionally? If you > don't care to disable, don't do it and this is even the default. I do not think we want to have config per syscall, do we? There are many other syscalls which are rarely used. Your changelog is actually missing the most important part. Why do we care so much to increase the config space and make the kerneel even more tricky for users to configure? How do I know that something won't break? brk() is one of those syscalls that has been here for ever and a lot of userspace might depend on it. I haven't checked but the code size is very unlikely to be shrunk much as this is mostly a tiny wrapper around mmap code. We are not going to get rid of any complexity. So what is the point? -- Michal Hocko SUSE Labs
