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 5ADCDCDB482 for ; Thu, 12 Oct 2023 16:43:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3F5D8D0134; Thu, 12 Oct 2023 12:43:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEF9B8D0002; Thu, 12 Oct 2023 12:43:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B76E8D0134; Thu, 12 Oct 2023 12:43:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8BBE68D0002 for ; Thu, 12 Oct 2023 12:43:37 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4DAC8C0794 for ; Thu, 12 Oct 2023 16:43:37 +0000 (UTC) X-FDA: 81337380474.01.AFF15B0 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf27.hostedemail.com (Postfix) with ESMTP id 7285540024 for ; Thu, 12 Oct 2023 16:43:34 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="N/9IA2GO"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697129014; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FheJ03zTB1r9h7STvwuIv4tGnbOBTf52Cw7EqZS0/H8=; b=vO6lzwPZkCRwRG9nK0tyTyu9+QvfzUx9xNpmR5RKOTjQ9t+ibS72cpMu1U/gCnbI5YKopN RAS7GoCaCfe1EtW+prRTdo57Kf0iiljqNVTK6mWlP5Xbq9LTopxjEnQI6vF1FAmHehOGm+ XBIcuTJSAxVc9opLTJFKAHQHfNe2vOA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="N/9IA2GO"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.178 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697129014; a=rsa-sha256; cv=none; b=UMpWIVTQQD3aPJFPpHZKhmrEu4HAT79g+aJNUiYcFUH1FRAfguvJ/zQiPM7O8LpqR+sExD 6ryDa7fT59185uY3aCvECtFivt7r5zxhm27iJILAonVuzahfYrm/YGRCrgkaGW+UKGBWPA jt4N7udkNcWbytpti1PuBO9B8MA2aHc= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6969b391791so928573b3a.3 for ; Thu, 12 Oct 2023 09:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1697129013; x=1697733813; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FheJ03zTB1r9h7STvwuIv4tGnbOBTf52Cw7EqZS0/H8=; b=N/9IA2GOvQtjItTDTkbCZIR8Wp4zPoslNmWrLtU1vgsycp6fIem9rjPblC9dFU4/3R 7L4HyJ8uzmSt9FPUSdu+Jk5VBeWvyRmdyKEgWNc21PPChAwD9Nt3/MOeJJfGN9VLdQ72 VQSupZWjMS6fLjdFuLTkabnrhMzfufOYB1TDs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697129013; x=1697733813; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FheJ03zTB1r9h7STvwuIv4tGnbOBTf52Cw7EqZS0/H8=; b=PWbCW2pp304m77aYduyvCdweegEbyQ0bBHq/q4VC4SwYDJSWIAeLHtouiwqgnHJWZU Aao6KUsqx6tqq0AmUFNLWBGfPnwxJ/8Xx+R8BveBvybnTcOF1ATicLLz9jUn/59PX7jI 3YWYgnLilp0WeVDnB+GM/c1DsRQq5kMk7JGkPPAq9bif54g+PZADNjyBOoZkaylOWvlu 0JReo0MYqbvLH3ueCYYLiL/QQMiCjDp8csIRUHwXm74WGFgKlvmFTEb/pAvZMku+8cBV /cTr5dYRhYQzdGNhOYF7DmEXtiJRhLndwcnkLoKcWGm4UJBCTn8G4p/u6UCDX/THlUG/ 5PWg== X-Gm-Message-State: AOJu0YyNNd63HqvVaazfojWRviBPYk9oNbRq2sewnhNrNJES7mq3+BSB 6JuM5pqdDj6kDkRb/Gw0zAcFiw== X-Google-Smtp-Source: AGHT+IHNYLYRAliVe1HCl7LxICrQAgkMgrh+0+zSF1yj3orms0Aj5ljjNrvRX7iZPDkay63VVPiNgw== X-Received: by 2002:a05:6a20:4287:b0:16b:aad0:effe with SMTP id o7-20020a056a20428700b0016baad0effemr19212702pzj.62.1697129013159; Thu, 12 Oct 2023 09:43:33 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id k10-20020a637b4a000000b0059d8ecb79dcsm1970301pgn.20.2023.10.12.09.43.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 09:43:32 -0700 (PDT) Date: Thu, 12 Oct 2023 09:43:31 -0700 From: Kees Cook To: Vlastimil Babka Cc: Roman Gushchin , David Rientjes , Julian Pidancet , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Andrew Morton , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Rafael Aquini , Linus Torvalds Subject: Re: [PATCH] mm/slub: disable slab merging in the default configuration Message-ID: <202310120935.E066A3FE4@keescook> References: <20230627132131.214475-1-julian.pidancet@oracle.com> <48bd9819-3571-6b53-f1ad-ec013be742c0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7285540024 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: orossj4mb7z1hofongf6cbon7m1dom5h X-HE-Tag: 1697129014-240822 X-HE-Meta: U2FsdGVkX18SHnRy4Thflwb86PufZimMrtHas82+qQvNcQpfcUDPxgaj6A4/w2lKNV0dq4J5I7xmUlhSyWhBSd0b6oOvjnFqjdS8Dccg1Utsg8YkoXd8Pth4Jrftwkf5ss4SHKy4/k6L0IgoKHA69yfQ48fSq2QM2uzQv8Vw9QMrTNXD78Y4+BC5hyh3R8n9+DXraIpix0O6FXWrza4bOUf3mBCi24xNfVYg5TNDtasw95+hK2xdVibg86felFql/c+Hz5Q/Ph3xrvPzh7E5BDtrlxsY559x8CziVSIRek+gCxUFllrd/dnUYsrXZoAbf4PKsHEC4zW7HbtPe6lWgr2jwhY+snkZ5sOD9p4yCcOUsKrYdNkz/a/nKo/oNYeAu40ff9tSec8lTOTyMXxSQeu9bfhoYXGoxmNKjENof8fPbgekGFiuib5WcTavRMYPtqNHB3UduaDNXLoFO81W5zK6tDN6s2wwUr3BP6QZgvl3REsnu8hM0hLIq94ffQNvD1aveYwlvujngdLbH2MLmiva4IQgSi8vI+EufAq+wB0vQPkVGh37LmeWrAPaIO8q3UljJHSwugihv6+RiZRmEVOcJhPA9DXgUO7LqbmXzkYKSliljmkf2kPyWCSt0MNxgHmovxiIxy3bHR+izE9g44+NjRns0n17kaDWT65KEwJjNVxQGZUkLo9p0bQXPQRn4WAwlSRTPQffhh+zmxYukVSj1GllgVbIf8C0OPtm/0h5pPUFdbaVWAPkxZ2GoLxCLW3ASg7gSdQCVMLpdPFd9L5gUu8ZCWrkKn6K3xuWD5++rhuNWhxZ4mgil1vbH1RJyGiOiFXUmQrRP7OU2nQrfOsC5VPxc0rb469kDOa+zjQ9kIaNRUcRuUtLw33iAepbbOQBnoCCZF8tYhBb/cCNY2rqxDNZWyYRbPKGIaB4JJODSRTjfLq3bvntLiOgKl8TPyd7lfwVSIkVoWDli9Z GAjOgbMZ Bcd2nP1neU1U/KR1+30Owze/uGrKf52hP4eE7PwtsIyxJZZsJfbOVyyCqDaNAMIcer7JQ7l0+g726qFNB6+fTRvdcjqkCDd1fy7l38GPBriu81RimXqhGqZbzAtzrA+81m5VFIBl8DCwdYTaM1mxNSQRKc4UlWSn39rGlxd6k1pq3x8nnCgUQyTHQpVBqITVxP7QggiStLbfpCTc5Wj+yEWndrLkCfk+r/t8MFLe+vrnxWUXr+JoBZo1gNdiMLMuEK8XVC3suCTRiEUVGlAOnNGwEPuVwqs3a12+6t/ra6B0TUuQSDLpsrGyUtNum+H3prh9cUOn07whqexhfaANri80AaRXgEYVHaS+oQlkboMP33F1+hUlhqyzopPJX77rQFaD5P60bumGFkBlIlCSJFqFSdOjw7QK0JAEMjgB8ohSGyAw0cDSHYUzjlPbQ/pqqctO/ylYAtnUEXDcz70rLJalhy2t6dNjst0D3zo8Fp6GaDmnvH+DLb093j0cJlAXD+inXxCTMLV+9hT8NxcKY9rk4I5LooRITzxVcxwaHQ/6dY9ecarbb7sl0kSvKZye2Y9i5 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 Thu, Jun 29, 2023 at 09:21:14AM +0200, Vlastimil Babka wrote: > On 6/28/23 18:44, Roman Gushchin wrote: > > On Tue, Jun 27, 2023 at 12:32:15PM -0700, David Rientjes wrote: > >> On Tue, 27 Jun 2023, Julian Pidancet wrote: > >> > >> > Make CONFIG_SLAB_MERGE_DEFAULT default to n unless CONFIG_SLUB_TINY is > >> > enabled. Benefits of slab merging is limited on systems that are not > >> > memory constrained: the overhead is negligible and evidence of its > >> > effect on cache hotness is hard to come by. > >> > > >> > >> I don't have an objection to this, I think it makes sense. > > > > +1 > > > > I believe the overhead was much larger when we had per-memcg slab caches, > > but now it should be fairly small on most systems. > > > > But I wonder if we need a new flag (SLAB_MERGE?) to explicitly force merging > > on per-slab cache basis. > > Damn, we just tried to add SLAB_NO_MERGE, that is if Linus pulls the PR, as > I've just found out that the last time he hated the idea [1] :) (but at the > same time I think the current attempt is very different in that it's not > coming via a random tree, and the comments make it clear that it's not for > everyone to enable in production configs just because they think they are > special). > > But SLAB_MERGE, I doubt it would get many users being opt-in. People would > have to consciously opt-in to not being special. > > As for changing the default, we definitely need to see the memory usage > results first, as was mentioned. It's not expected that disabling merging > would decrease performance, so no wonder the test didn't find such decrease, > but the expected downside is really increased memory overhead. Did this analysis happen? Apologies if I missed it... > But then again it's just a default and most people would use a distro config > anyway, and neither option seems to be an obvious winner to me? As for the > "security by default" argument, AFAIK we don't enable freelist > hardening/randomization by default, and I thought (not being the expert on > this) the heap spraying attacks concerned mainly generic kmalloc cache users > (see also [2]) and not some specific named caches being merged? > > [1] https://lore.kernel.org/all/CA+55aFyepmdpbg9U2Pvp+aHjKmmGCrTK2ywzqfmaOTMXQasYNw@mail.gmail.com/ > [2] https://lore.kernel.org/all/20230626031835.2279738-1-gongruiqi@huaweicloud.com/ I'm a fan of turning on any of these "by default", as that's been the historical approach, which tends to span years: - security feature introduced, default off in the kernel - distros enable it by default - kernel makes it default on So perhaps we're better off making the other hardening features on by default since distros have been shipping with them for years now? -Kees -- Kees Cook