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 A6292CD13D2 for ; Mon, 18 Sep 2023 18:05:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 345866B0401; Mon, 18 Sep 2023 14:05:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F5926B0403; Mon, 18 Sep 2023 14:05:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E4BB6B0404; Mon, 18 Sep 2023 14:05:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0DAEC6B0401 for ; Mon, 18 Sep 2023 14:05:54 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D5926120B3B for ; Mon, 18 Sep 2023 18:05:53 +0000 (UTC) X-FDA: 81250496586.20.E22643C Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf29.hostedemail.com (Postfix) with ESMTP id C5CF6120010 for ; Mon, 18 Sep 2023 18:05:51 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=G8u2WIRC; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695060352; a=rsa-sha256; cv=none; b=GhFb8WF0XFmCpxSNvEFFyVgbALQNuJiMnjol67tCIurs2skIz0SE/ZbV2+UlXtCazAOP3X AAjRYON9Ob9phKDC9JNQvw5EXTnfz0BcFBov15UWNs+iNV9zVA0+F81GnYVwjiphlrusKQ ELpyLu8wNs4gWUWSEC55h3zTKripfro= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=G8u2WIRC; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695060352; 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=q9he4ZTvSFJmzzOtbECfSpps3SrCLJMjInfE6GKKq3k=; b=4rlWMxglqVo9oOnrGjaxNwSr6RLNRMk6CQcxCBIYWMAbWf+KFhytAczLAsYSTMDJtP9EIi z+GCatVpXPUMmSMpQbRqjc8fGwGzca/hHQFEd8TgmDyRg6r1dy5Otf1Y3QZnGLX7zh+1dM tRquv2AyH+pX42pxvOs/Wrbus+vZP3g= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-501eec0a373so7806494e87.3 for ; Mon, 18 Sep 2023 11:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1695060349; x=1695665149; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=q9he4ZTvSFJmzzOtbECfSpps3SrCLJMjInfE6GKKq3k=; b=G8u2WIRC9a/DbljFNLuoYW7SDEIp5TG+V+7tG7YnEGvig4a/hTD2bcdbFqcyPM1TYD q2Td/Vm6I8opyUFKYadhK98vt/+/IzzW+QSYYebWEnt9HYht4MGReOn46EVMmasEH8GD gGMpFI7/rBjXgk/AZA5dRhIR0LxMUFyUaFf8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695060349; x=1695665149; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=q9he4ZTvSFJmzzOtbECfSpps3SrCLJMjInfE6GKKq3k=; b=hPpAZi5V52lQTwdeC8dFMSeXhlujIaqtySSGAF2oGJIl7VN5bwpOhD7RS2uRZ55juD /4Iq9aNwL65kspA8x9KeyVFxspgEUcSIdqLr2EtyWkW7Zqpk2n8BtimhFyl9o8VH+RYO MsVtZdG5xJ442H6WQaogfsXcStrmr50lbg6yD5bpUR6Na7FMuw0bC0HflWfnuGYeoyL5 V6WM0b0LYrIwr7HGBfBUn1ntxbbQmf82mp6fdWuRbi2w8OzdP85AOTCd23i3FYznJq+A a9WFuEMq95vKbRG3JGvfG1JND4KzQCTT+smwy0+dgULYb8HcdcjTDnp5C6Yb8ltSZq6a kD8g== X-Gm-Message-State: AOJu0Yyp0XWwZ9Rta60SBFEWwoEarUeOBiSADr3lQfdGDwnyZiXCe4ru PQkSPUXXxzB+QJvIzlmx/wATUvzKRV3j5DFMdQ9m9RRU X-Google-Smtp-Source: AGHT+IGwpTjAe9yzxue8cu6kasJBUOqsR+4rrDGri6S2Cpvu4zxzCjvXLKumUh5z1cGMByGb4dHwpg== X-Received: by 2002:a05:6512:2526:b0:503:294d:78b with SMTP id be38-20020a056512252600b00503294d078bmr414505lfb.46.1695060349442; Mon, 18 Sep 2023 11:05:49 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id lc25-20020a170906dff900b0099bd86f9248sm6763732ejc.63.2023.09.18.11.05.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Sep 2023 11:05:48 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-52a1ce529fdso5862570a12.1 for ; Mon, 18 Sep 2023 11:05:48 -0700 (PDT) X-Received: by 2002:a05:6402:2903:b0:530:d53c:b4d with SMTP id ee3-20020a056402290300b00530d53c0b4dmr5507496edb.35.1695060348351; Mon, 18 Sep 2023 11:05:48 -0700 (PDT) MIME-Version: 1.0 References: <20230915105933.495735-1-matteorizzo@google.com> <7a4f5128-28fd-3c5f-34c2-1c34f4448174@intel.com> <1d7573c0-ebbc-6ed2-f152-1045eb0542f9@os.amperecomputing.com> In-Reply-To: From: Linus Torvalds Date: Mon, 18 Sep 2023 11:05:31 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator To: Ingo Molnar Cc: Matteo Rizzo , "Lameter, Christopher" , Dave Hansen , 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, keescook@chromium.org, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C5CF6120010 X-Stat-Signature: 5sw959yhu7nhqfeb5q3w8w8m3z6e1dt4 X-Rspam-User: X-HE-Tag: 1695060351-460368 X-HE-Meta: U2FsdGVkX1/ld041KnKNwUQ1o9BA+Vp8G00ZIfukxOxKC5kPbKlo97C7+j4RAmoIaInpn4J4zqLFwiVRgFf6jbWAJj3b5/tIFpyp3ln2+HS28qls4YO9CDrZw6DjuJqTo7BIANAHfDTMJR/kM/kyA8wlIotOVEr+sBuAg4pX2lJWEwx5DlUMX5hZnSCJu6+VRZnuuKjxSHVBGZ0uvW46/urMt1Pcsz5DfyChsdga0G92V2VgngdkIdDbMmrTUhU3B+Yde/m9zvYp13jqlKdsafR3ybvlsZ80l8y3ajJCewyBq5x4fwf38lxtMk9pwGvmOpHFqCmAw169U+Yc+f6dsVYb8SRYNwOhvby16znJ+xDR0BqWCsTRmFoM/eGjI5krQt3rddnNeWUNL+/NnWrYm+aYO323rS/UVR7rgACOae48VBbDXr8eYkCnaDpQ0DHJu/GUyzfwYDyro57uoQhpDwU//3KwfAWqLsKT0omtW/UAhR5oVSgY7Pz0MAG5jj+ysYc+r3NiS8qfDIReF/aAGIWreCVkOLJ/dwpg3Zj2FcLA9f2jMGhrOeeVCuLXdsvYxpEG+JV/rJTrzZNe71V2eGpbCdPI3dqympw1fWMFsXgpKgFsWrP8kHokUC4DSm1MaVky6XFCIQYabjtgEfgyNnO/yWz2oHyRypK/+3aXXxjkr7gQdO6674JNHgnoLIUmNQe354skRINgcZODSz2quCcmd6tDCdyyjMMh3VyauwGOxC3yjy/2gYPoW8rcBuUxtcA7wRipLp0Hadw0eGVp3qCkEpDP0Rbdv6hXStkDkgGI27l07xKkgak1/gJyjcmx84uY2iDXMn3sj4mVcHh8ccYTsga6ILWg2uHRWAK+FP39s77d4GZu1m/a9GO2hPu0FU4HLEeJOeiy2SyU9W7AoQZkA8dRk/IF5iQyPlLzFAgR7cXku4KVy5aO56Yhgu5Nktg55O4hu3oID4WNSr/ Wreqr6fn /3IJSl85X5IXB78klPQoakR1o043RW2qKJWhv1VKDg6PF2ln6m05xx5/rWWDYr/T6UDU2xViRaPhFuJNZih4tSt1AsNnhiD8syJo7C0Pll3a+2aCMpM0fUwnKB63Vz4faHuR7lNAiX5R51ggjGgQ2OdwkEDgTCGcKF0/nL7cBlydOPamkHgWWRU4soeJIkm47M4OZ4+t6nSKXidQISWBJlxeKj7UD9tZMTof0ZzLhBM0dyMujjuGV+ug3PhLxnbqoOiguNLi5IgqI3tt6oISOZ5qsd2iTbf6jUORQgdY4uKFa5cem86rRZXYfzo/NVoTQ3twmkrs8SmJ8kgHL8tcEl+PqhsZ5wq+Kg9SHkHfHJ0SVUU4wNavp3ORddqxvOAOlg7CwTKQ+iMQdcUohyhrO8Yk4x7PlT7EU7PSacZkh4ZB2mWkReFeoyJ3sxDLjggZDwv5ZTdw4DNBNvuRQKGaLHWJS6Pr2AclzndY0nK0NYqiSsX+8BRDxLjKBT7ZqRL2pAn3KEruVr/k0H1080huZ0yOTFjxgv0TizlgoreLo2ZXbt5CnWuyv+hPBUwjWu0Nk1+ZyShckMahvPI6DnqSjTF+vY9ypZ7z1Xbw+dK24l4J9LebE6p9ahoTRV6mRVS9H8SHe 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 Mon, 18 Sept 2023 at 10:39, Ingo Molnar wrote: > > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between > user-space execution and kernel-space execution? ... and equally importantly, what about DMA? Or what about the fixed-size slabs (aka kmalloc?) What's the point of "never re-use the same address for a different slab", when the *same* slab will contain different kinds of allocations anyway? I think the whole "make it one single compile-time option" model is completely and fundamentally broken. Linus