From patchwork Fri Aug 30 09:56:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?UGV0ciDFoHBhxI1law==?= X-Patchwork-Id: 13784842 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9F40CA0EFC for ; Fri, 30 Aug 2024 09:57:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48B166B00A0; Fri, 30 Aug 2024 05:57:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43B2E6B00BC; Fri, 30 Aug 2024 05:57:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DBC36B00C9; Fri, 30 Aug 2024 05:57:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 09DDA6B00A0 for ; Fri, 30 Aug 2024 05:57:04 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A472241746 for ; Fri, 30 Aug 2024 09:57:03 +0000 (UTC) X-FDA: 82508458326.29.BC1DAC4 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) by imf25.hostedemail.com (Postfix) with ESMTP id C64CAA0010 for ; Fri, 30 Aug 2024 09:57:00 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=isc.org header.s=ostpay header.b=iRAUpXCf; dkim=pass header.d=isc.org header.s=05DFB016-56A2-11EB-AEC0-15368D323330 header.b=iSZPtY5N; dmarc=pass (policy=none) header.from=isc.org; spf=pass (imf25.hostedemail.com: domain of pspacek@isc.org designates 149.20.2.50 as permitted sender) smtp.mailfrom=pspacek@isc.org; arc=pass ("isc.org:s=ostpay:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725011721; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=yQqeysRA7BvACQoikxWHOQ42EW7pELM6Da6x7deyM9I=; b=zYlP54oTEiXfp0wYyk/2k+9M7Xc1D7aTw+8kqM9r+iBq1PH0RZUTcH7CcjRxegXvhLhL7z gIea6vDbpP95UNshn3O/wQArLD5iESvsMN2UnqoAJ69JRhFaSwtWHYf2cp7B6XbXC82RBQ yPNW8I6/sIEvVVGbt/QfeCMhAI26e8U= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1725011721; a=rsa-sha256; cv=pass; b=cYZ1KW8RhFVoNNV3kZWThS7QaRq1Mgt0OW18VLYvYeT4fDexqcIItmMu98GKPFB405kaQ2 sLRVvp3BLNrPhjwlMQzpvYVFvjJXuFEhwpbFbpoakLlaeghkvkKZorAyrNOyP22ZeFvxSm lqCN7fQBsc/QNMTMAEORc2VDT1HGY5Y= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=isc.org header.s=ostpay header.b=iRAUpXCf; dkim=pass header.d=isc.org header.s=05DFB016-56A2-11EB-AEC0-15368D323330 header.b=iSZPtY5N; dmarc=pass (policy=none) header.from=isc.org; spf=pass (imf25.hostedemail.com: domain of pspacek@isc.org designates 149.20.2.50 as permitted sender) smtp.mailfrom=pspacek@isc.org; arc=pass ("isc.org:s=ostpay:i=1") Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 26C663AB294; Fri, 30 Aug 2024 09:56:59 +0000 (UTC) ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 26C663AB294 ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1725011819; cv=none; b=ccTJi2pfy/pZUC8zvZbDttdt+gd0ol4uLA4sRH9Si9dB9GikQ5/UzfTXNfK21kVEPWnYSjc6CgVT8cQeAmxoHEz5Y8kTObSanJIra+LP20H3ATW8L0RboU838nEvnkInGC4Nytysfi7o1ftlNHtjDuehn43i/Q8SO8YT+yUlKDo= ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1725011819; c=relaxed/relaxed; bh=yQqeysRA7BvACQoikxWHOQ42EW7pELM6Da6x7deyM9I=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID: MIME-Version; b=NY0LbN0YhsFsDIiGNn+rhl4TS14bTNICMHaHLtOFP/0zi2eDKMuH1Xd5NcDPHZQZHJdy/TDZ5LAcm4+JhvbAKFvITbRrFQU0Q+N+Qa5/WdYxHBa+6dFjhCgLiWIMu7y7QwPd4dwTGR/+qZ8/91F5lkKVcwaI2b6TTzrcf/VJCig= ARC-Authentication-Results: i=1; mx.pao1.isc.org DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 26C663AB294 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1725011819; bh=cgBmCHdRwUxF+qGn4iXkZ0PGffsChnB8Atnoh1RJ1qA=; h=From:To:Cc:Subject:Date; b=iRAUpXCfD0JG4nW9fZKuGzTR50zKk7hwIM7OLp8e72ljUlj0Jnq/GtyQwny1ckvz9 YqQgkeuhPb147lKylC/ib+N454DpEPgk490xwI5SVBE3qUb5DMcVQc6ED9dzZuzORg Ym+htdQnMjlCrUus471W/7sbzI0pBQn+9dI/h5j8= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 20EAA110BEEA; Fri, 30 Aug 2024 09:56:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id F3E8A110BEF4; Fri, 30 Aug 2024 09:56:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org F3E8A110BEF4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1725011819; bh=yQqeysRA7BvACQoikxWHOQ42EW7pELM6Da6x7deyM9I=; h=From:To:Date:Message-ID:MIME-Version; b=iSZPtY5NdSqXe8NyHXBMWQ5inf3T6xjGTbt68yBuwcZukf4fFDIl+XPjJQiIixpx1 lV3V3/6kUjaK/xUYEwoB5RBH2KSXGt4o8XNo5iyrUfY9KpGVkM3CFG3AE3M1M7KWHo 56tGgeqaXoA6f/YBkeRc4K7kWlLEYLFiOyqRlJpU= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id dkC6QH7jNJyl; Fri, 30 Aug 2024 09:56:58 +0000 (UTC) Received: from localhost.localdomain (unknown [149.20.5.121]) by zimbrang.isc.org (Postfix) with ESMTPSA id 277E8110BEEA; Fri, 30 Aug 2024 09:56:58 +0000 (UTC) From: Petr Spacek To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Petr Spacek Subject: [PATCH RFC] mm: mmap: Change DEFAULT_MAX_MAP_COUNT to INT_MAX Date: Fri, 30 Aug 2024 11:56:36 +0200 Message-ID: <20240830095636.572947-1-pspacek@isc.org> X-Mailer: git-send-email 2.46.0 MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C64CAA0010 X-Stat-Signature: jrmh3z3u3qmchrboeybkzcw9ra1a1my5 X-Rspam-User: X-HE-Tag: 1725011820-42564 X-HE-Meta: U2FsdGVkX1+c/u/nlIB+ysCdcRXLsRIzL9HUbV7yW3BJGU/lWsWx1ztdjBCZ1FSOnrXPf57er8QgDn5ViCdQjSjlf5Bje3yB/bopEaggFvPLCSr3OeXhdHAsfEYjU2Shlh5Q3OtAsspZ0Q5+hBDnDmLfxBrcsDl8RXCsmX02Rr2uebTn3hdaYmzr6qWZLpC+4OvVhzNJuFbddx6gn0x32jcauzh2ft5ozuTHgJpQiovZoevkRafP2U/KXk/TrWBHww401PgclIvand8SpXsoNI3igMpMRzBUrzkIvTlSGXQqjIFNtXycl9aQyT1plKP1PiE+BHmwasjKQpC7pwk1BTSJW4iB7ExBlHY3CxgDc0rTrjgKyIlj43HQnB13uDfourk+WSwY/3/3HrZJ40M2Xo+yLTznSXARmxGtrULaTF7uvqEKnkpf8ipUn+0tyBo/Dfa0XK4kcx9quU642PhXHsyn5BnYAf74DPkOytUWUVLSjzJVVlQYqHMJgKDzs4VyVWnV4Gljp3YH7C7qY3nlZi8Lg84mWwyEVCsnq0dwyfH9+vMg0NJKsOqnkJGAS7PH4Q6hmzggMfQ+di9x/0U+1g4CawdTqxQoFJSuxMoVU1OAD/mQMgw/nhqYkB8HgSFzuDKNwQ6c9KQIlhlPKRvC0iK3jTEFFNfrxzPNT1Hhi+WaXdeO4eEdvhZB/GQU4sHTcJz8s5WOm3RHV+TXNNHy6DsHUsrw8PnCwvzT+m0tfxY+jj+HEWdUJbBvkfi0cM/OeOdAem18FhQP4Mgf/dqaXnWV8jM/uJcrD8w8ooAfb2ByWY5eUUN7QZJ9DeO4TRalsRwqTPGJ950o4yWqCK7oOYFFlGW7MA5SXbkveJAX3YKaWpCZVvD+SQorpsUZw3v5uUNoLSxqgo9+4zkQJyG7kZhUjr7e+4uQrYZYpWHGWsHxLtJ+0bH7pwlopSLuTcTvXFUnNXYz4djfC0/de/l CGgWeJvD xGim6Ygt+BQmjTxLzA9AEs13ovaHNx5nzqBuZbomBRnI67ZTfWN3pN769BAxvpnmTzQAkP5PwOMJKz1EIyi8AJLbh7CeJTfXEv8CSBjKCFv+uoRt589CsfdXofxo3YhSOxD4Vg4agFtGpJ4mF7iMehpi3PyimDtXLqLrqHBf2UsRaItjWSWeUPAb4jqO2Cpoq6dlBvO6TnYHv4qPPz15RONSKHwSmZNIFNY9Oets5aAfIC1Xo9SYsXkbZVKEQRde5wmrZ635dfUh5SNuA3s6ZnovGez8D3XOnMxHeWxt8KHf7tDynvF/k2fD+GRfsPXkzd4GTNmk8yCzyopra8/dIoQJQ0Tkh6yRTHW3xQrB4U+XgNOXHCgFj7VH4N/uzOF7wT3DjyZs3rK1Crj6WxCuDkQYZmin1StQXhRoopgfuXxcsd9Vq2obMBZ8yFv4N0eh+gNNwa6vPotmDGwzrww7odcvOoD1vapGaBSiVauof8Vry9npWGsP1p6UIooZq+o6cweAz1st8Xwg9UW7ijQnqbJ5QwhZNAyg8J+9igtSpNy6Er6w= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Petr Spacek 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 --- Downstream distributions started to override the default a while ago. Individual distributions are summarized at the end of this message: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/5GU7ZUFI25T2IRXIQ62YYERQKIPE3U6E/ Please note it's not only games in emulator which hit this default limit. Larger instances of server applications are also suffering from this. Couple examples here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/24 SAP documentation behind paywall also mentions this limit: https://service.sap.com/sap/support/notes/2002167 And finally, it is also an issue for BIND DNS server compiled against jemalloc, which is what brought me here. System V gABI draft dated 2000-07-17 already extended the ELF numbering: https://www.sco.com/developers/gabi/2000-07-17/ch4.sheader.html binutils support is in commit ecd12bc14d85421fcf992cda5af1d534cc8736e0 dated 2010-01-19. IIUC this goes a bit beyond what is described in the gABI document and extends ELF's e_phnum. Linux coredumper support is in commit 8d9032bbe4671dc481261ccd4e161cd96e54b118 dated 2010-03-06. As mentioned above, this all works for the last 12 years and the conservative limit seems to do more harm than good. include/linux/mm.h | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) base-commit: d5d547aa7b51467b15d9caa86b116f8c2507c72a diff --git a/include/linux/mm.h b/include/linux/mm.h index 6549d0979..3e1ed3b80 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -178,22 +178,19 @@ static inline void __mm_zero_struct_page(struct page *page) /* * Default maximum number of active map areas, this limits the number of vmas - * per mm struct. Users can overwrite this number by sysctl but there is a - * problem. + * per mm struct. Users can overwrite this number by sysctl. Historically + * this limit was a compatibility measure for ELF format predating year 2000. * * When a program's coredump is generated as ELF format, a section is created - * per a vma. In ELF, the number of sections is represented in unsigned short. - * This means the number of sections should be smaller than 65535 at coredump. - * Because the kernel adds some informative sections to a image of program at - * generating coredump, we need some margin. The number of extra sections is - * 1-3 now and depends on arch. We use "5" as safe margin, here. + * per a vma. In ELF before year 2000, the number of sections was represented + * as unsigned short e_shnum. This means the number of sections should be + * smaller than 65535 at coredump. * - * ELF extended numbering allows more than 65535 sections, so 16-bit bound is - * not a hard limit any more. Although some userspace tools can be surprised by - * that. + * ELF extended numbering was added into System V gABI spec around 2000. + * It allows more than 65535 sections, so 16-bit bound is not a hard limit any + * more. */ -#define MAPCOUNT_ELF_CORE_MARGIN (5) -#define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN) +#define DEFAULT_MAX_MAP_COUNT INT_MAX extern int sysctl_max_map_count;