From mboxrd@z Thu Jan 1 00:00:00 1970 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 45149CD37AA for ; Fri, 15 Sep 2023 21:49:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B88B98D0033; Fri, 15 Sep 2023 17:49:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B37F48D0005; Fri, 15 Sep 2023 17:49:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0BA68D0033; Fri, 15 Sep 2023 17:49:58 -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 915E28D0005 for ; Fri, 15 Sep 2023 17:49:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5CE391407DA for ; Fri, 15 Sep 2023 21:49:58 +0000 (UTC) X-FDA: 81240174876.24.DCED2CC Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by imf11.hostedemail.com (Postfix) with ESMTP id 490B040003 for ; Fri, 15 Sep 2023 21:49:55 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VKifdXzB; spf=pass (imf11.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694814596; 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:in-reply-to:references:references:dkim-signature; bh=fT0RYAhKFL5s9KGOOHYAB1PNLpHii+TuCg+Ufd/DsYc=; b=TaGkjykBQNCI+QEL1Qkmw8mkfrFyqkdzPyh4waYJ92WUtMggTOAYBUtkIRYFG/A3DLIRM+ 0cgvA/a84S8Wzio7KxxhYOsbTsq4IhvU2qCVPblJjpb2T3dxWtEXinw6UN2LY9verXVXcG BuDjNVN+bld/uc5UpmMInhkQFa3nrr4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694814596; a=rsa-sha256; cv=none; b=1ComVnYF365VdPhq/fugPFAaNgz+9uYNrOorE/Mqw7g9ej5DZ2wkR8FqTrMSwYKUJocf7O HUtV2ZhdEv1CVuojmNGYilXwb398IEeE3ZblgxUc3bq6TacdF4KVVbI5m82/dCewsE3sDM K9MzMaccj2ecNkNg4GBOvNQxPLf0GxU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VKifdXzB; spf=pass (imf11.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694814595; x=1726350595; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Q2f++CQ4YvVjqHtWEWqnDjoY5zgYMBznv/GocztfsC4=; b=VKifdXzBuz5qwUhcSbNQ1EifrVNQDwF1F4YWYqAL4TNjzwRM5oR5bHob QdlRMRXUIYiRVMQPEFrmd9hFpwbvgUrDsKBJ8RsLXh6cwzC+JMOznVrKv 2i3rU5ADA3Ft/0BYhiWV3Im7DjqjiaKb7bgrlZDGr2J8kojTAVwa1l1Sg wPyrFDIVvRiRjNbypqhKW3fqHHNhZSu/+vR0fXkHThzv6gNHNxW1jH+F8 K5WfFLd5scMKHkz44UF8y5TvSDjrZht7dQIFssUnwl8UmakvEr1q6UFwJ Jxq7wEwZ4WaP0vamMdFeXgwTjuTnKSlOWi22YRxa+LSqdTq3RTftOhe2Y A==; X-IronPort-AV: E=McAfee;i="6600,9927,10834"; a="358766841" X-IronPort-AV: E=Sophos;i="6.02,150,1688454000"; d="scan'208";a="358766841" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2023 14:49:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10834"; a="1075917495" X-IronPort-AV: E=Sophos;i="6.02,150,1688454000"; d="scan'208";a="1075917495" Received: from spswartz-mobl.amr.corp.intel.com (HELO [10.209.21.97]) ([10.209.21.97]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2023 14:49:52 -0700 Message-ID: <64e62982-6d0e-f742-be5c-15390d8e7c2b@intel.com> Date: Fri, 15 Sep 2023 14:49:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC PATCH 10/14] x86: Create virtual memory region for SLUB Content-Language: en-US To: Kees Cook , Matteo Rizzo Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, corbet@lwn.net, luto@kernel.org, peterz@infradead.org, jannh@google.com, evn@google.com, poprdi@google.com, jordyzomer@google.com, ardb@google.com References: <20230915105933.495735-1-matteorizzo@google.com> <20230915105933.495735-11-matteorizzo@google.com> <202309151410.E65B8300F@keescook> From: Dave Hansen In-Reply-To: <202309151410.E65B8300F@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: tywqe1io39nhik3mn49oiwd1ie7aunrh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 490B040003 X-Rspam-User: X-HE-Tag: 1694814595-653301 X-HE-Meta: U2FsdGVkX18BMv4N4emTtKg/IHE4PBL2ipksQ3Fo6zPTLh1xkXKVWy3m8vjhH5dWsOsYXlb1GRblo76typErG/M71HWx5u3j0Ak0WzhiQUvaXy7MVIwH3Gty1F85KUErwgR9nRmo7DTDlmqmCMMPYNIlGA6YeMU3jIOnbogtPs78dmsleKkxyxEA43KYPdkjELceoX6VZDRE9Blo10T4WxNGLwzPMn8oRtkT5cDE9Opo7QODUDdXqgpMnyiAxWg6c+6ICgN58EYftO4Bj0740WlQQFBONQ+GgpF3hEyddceit6RDTB8bmTck/1S3lBmiAuDydNgNlWpT/2dhwKYH3o6PwOWEhIBplibIVB9qfxCK+/Fpizpuuf7Js0llIV7ybDHqFaMUrJ5arvd3xSIDPdz/OdiDX2wh8nfUr5+Yweff/C9RqESoa17ppiF0lZbW3KZTHxtP08O569hSCEX/bw5d9Z+5EzMa5HPlxkyAExHBv8wpMQlbtYH5E2sMI7ohlctYKbNESr/6FDspWEL+ROS8PNso5oK7Bdsiv0X6P2844vVsFQhpNO/boviDLaKOEJFrYa9iDkO+SqxqWMNsnut6vVQ9gxL5kfhrc331LikTSjR7qMCv+/O0iVtbEd/9mFjdxspgKD4Qvk4YkVev4Nx08CXhjCi9LVHzcisg5DyoEcC43ZntjBY3ZQ0u4LnhH7b2Sd+P4AeXSxhpaUidHaZVBj6fCk11YPsqiAe/QjzgaaPhNvyqT32KufwkZHoWRN1RdHQ+EsUl5D6Mim/qz33BgvHt6p76lytMG9GFbIeIyv1RMHjYPWaA5SwaLZlhJUVe4iUSTt2ABAdHZ1vulG95NJTOeVurTrx5WyovjggjtMYNMnUanT0WKzuNMw+6PVlu0/StSYFPzBcXrdMCGiqxjWMp27ccneCLOn1vAiJYs/H3ox2zzWxvWr0YM0Gd368c5jAQSDLfNBYD9Ke BoqltCkx RiSy7yg/qCLIm6qR5oQ8NbmxVAz/m4JN/3RGX7aj1RDrZURN+IzsOohW0Ksn+rgaC+m1T8Fh8keX6C5omXHAZQ4kK9IzndElnMFhEiJiXx2cW5tSoyQ0Eyb+VhNW6aNZiVr68s4kFGONJChv2F1CPlsr7yYeP5oTCLbWV5fJLhN2alqAkeZw2V2tJIsdxwAGynM99VnsIkFNjYgNQGwu614r+m8uUxwS7q40uy/AZ00s1DWw= 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: On 9/15/23 14:13, Kees Cook wrote: > On Fri, Sep 15, 2023 at 10:59:29AM +0000, Matteo Rizzo wrote: >> From: Jann Horn >> >> SLAB_VIRTUAL reserves 512 GiB of virtual memory and uses them for both >> struct slab and the actual slab memory. The pointers returned by >> kmem_cache_alloc will point to this range of memory. > > I think the 512 GiB limit may be worth mentioning in the Kconfig help > text. Yes, please. > And in the "640K is enough for everything" devil's advocacy, why is 512 > GiB enough here? Is there any greater risk of a pathological allocation > pattern breaking a system any more (or less) than is currently possible? I have the feeling folks just grabbed the first big-ish chunk they saw free in the memory map and stole that one. Not a horrible approach, mind you, but I have the feeling it didn't go through the most rigorous sizing procedure. :) My laptop memory is ~6% consumed by slab, 90% of which is reclaimable. If a 64TB system had the same ratio, it would bump into this 512GB limit. But it _should_ just reclaim thing earlier rather than falling over. That said, we still have gobs of actual vmalloc() space. It's ~30TiB in size and I'm not aware of anyone consuming anywhere near that much. If the 512GB fills up somehow, there are other places to steal the space. One minor concern is that the virtual area is the same size on 4 and 5-level paging systems. It might be a good idea to pick one of the holes that actually gets bigger on 5-level systems.