linux-kernel - Re: [PATCH RFC] mm: mmap: Change DEFAULT_MAX_MAP_COUNT to INT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <82960a7e-9013-475e-9b80-7b29a5667482@lucifer.local>
Date: Fri, 30 Aug 2024 13:01:19 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Petr Spacek <pspacek@....org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Vlastimil Babka <vbabka@...e.cz>,
        Liam Howlett <liam.howlett@...cle.com>
Subject: Re: [PATCH RFC] mm: mmap: Change DEFAULT_MAX_MAP_COUNT to INT_MAX

On Fri, Aug 30, 2024 at 12:41:37PM GMT, Lorenzo Stoakes wrote:
> On Fri, Aug 30, 2024 at 11:56:36AM GMT, Petr Spacek wrote:
> > From: Petr Spacek <pspacek@....org>
> >
> > Raise default sysctl vm.max_map_count to INT_MAX, which effectively
> > disables the limit for all sane purposes. The sysctl is kept around in
> > case there is some use-case for this limit.
> >
> > The old default value of vm.max_map_count=65530 provided compatibility
> > with ELF format predating year 2000 and with binutils predating 2010. At
> > the same time the old default caused issues with applications deployed
> > in 2024.
> >
> > State since 2012: Linux 3.2.0 correctly generates coredump from a
> > process with 100 000 mmapped files. GDB 7.4.1, binutils 2.22 work with
> > this coredump fine and can actually read data from the mmaped addresses.
> >
> > Signed-off-by: Petr Spacek <pspacek@....org>
>
> NACK.

Sorry this may have come off as more hostile than intended... we are
welcoming of patches, promise :)

It is only because we want to be _super_ careful about things like this
that can have potentially problematic impact if you have a buggy program
that allocates too many VMAs.

It is a NACK, but it's a NACK because of the limit being so high.

With steam I believe it is a product of how it performs allocations, and
unfortunately this causes it to allocate quite a bit more than you would
expect.

With jemalloc() that seems strange, perhaps buggy behaviour?

It may be reasonable to adjust the default limit higher, and I'm not
opposed to that, but it might be tricky to find a level that is sensible
across all arches including ones with significantly smaller memory
availability.

This is what makes choosing this value tricky, thanks for you analysis as
to the original choice which does seem less applicable now, but choosing
something sensible here might be tricky.

Also there may be _somebody_ out there relying on this limit being quite so
low.

[snip]