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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B09D2C64EC4 for ; Fri, 3 Mar 2023 20:08:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231663AbjCCUI2 (ORCPT ); Fri, 3 Mar 2023 15:08:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231539AbjCCUIX (ORCPT ); Fri, 3 Mar 2023 15:08:23 -0500 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1AE913DC1 for ; Fri, 3 Mar 2023 12:08:22 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id da10so14950194edb.3 for ; Fri, 03 Mar 2023 12:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1677874101; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=icUeuEqvqPbQnLnoTJFmZqOp/anQ4LMobszRgORXgsw=; b=TDRqKYNlaFjGJRfXNmOIUGOwy4UL8l4YqkENlHDD/aan5Eez3v8eXzQg0eyHmIRWSf EkSZ7ejXEvxO4jJ0JU6tB+uMDU3kfuY31pQsV9fXDf9EblIb2A0sIiziH1KoBwYbkuUy yQFjcNskaa4E4PcnBPbP6vV/amExzZMAZ7kB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677874101; h=content-transfer-encoding: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=icUeuEqvqPbQnLnoTJFmZqOp/anQ4LMobszRgORXgsw=; b=LhGvZEdNp9RwRS4TmaCw6o5rRzB84H6YZz2/0kl9eLb9OnAWpcTl8I3+MKIGRqOuhY Ysj7UM86yT2dqGxmoiFd8Prw+Xc1672haF8muvHZgn0Yz7fNO7p3wxx2hbx48I7JIsXs PLa639+m9x7FI6Y+DQO7Jsnsit3ODMxc81ZRCefDVuVOUzudS6wezI9aNWF0GBEs/o60 wqnWylgHpmp3mjeJeNv2FIfbN30wpL08E+GUjg+bvNgWxbb3DodgYXEgf3MJ1K6pgyFu atKPW0d7YFWh+8zEQ7pgBzhGsbWJe8dX3THUfWQTzHXI7Zx/9i1pSyIsasiv68FS7ICQ NwSQ== X-Gm-Message-State: AO0yUKVC3gQvVSwZSnjBX11XRxQ9JUIKIkmGsqEWtbsY6Rwle/fzVuEa H4ku12pHJPlNeqXl0XWfuIgWfkgcvbDAGngs99c= X-Google-Smtp-Source: AK7set9YtW4fOhDAd/zF/dFByg1rn99SP5be45giAin1sl4Y2TaVVR7BvAhcjTcCoUPCI8DT5LqO0w== X-Received: by 2002:a17:906:dac9:b0:8d9:8f8f:d542 with SMTP id xi9-20020a170906dac900b008d98f8fd542mr3165366ejb.32.1677874100743; Fri, 03 Mar 2023 12:08:20 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id d8-20020a170906040800b008bda61ff999sm1290136eja.130.2023.03.03.12.08.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Mar 2023 12:08:19 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id d30so14933262eda.4 for ; Fri, 03 Mar 2023 12:08:19 -0800 (PST) X-Received: by 2002:a17:906:498e:b0:901:e556:6e23 with SMTP id p14-20020a170906498e00b00901e5566e23mr1471718eju.0.1677874098906; Fri, 03 Mar 2023 12:08:18 -0800 (PST) MIME-Version: 1.0 References: <20230302083025.khqdizrnjkzs2lt6@wittgenstein> <6400fedb.170a0220.ece29.04b8@mx.google.com> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Mar 2023 12:08:01 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible To: Mateusz Guzik Cc: Alexander Potapenko , Al Viro , Kees Cook , Eric Biggers , Christian Brauner , serge@hallyn.com, paul@paul-moore.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 3, 2023 at 11:37=E2=80=AFAM Mateusz Guzik w= rote: > > I mentioned in the previous e-mail that memset is used a lot even > without the problematic opt and even have shown size distribution of > what's getting passed there. Well, I *have* been pushing Intel to try to fix memcpy and memset for over two decades by now, but with FSRM I haven't actually seen the huge problems any more. It may just be that the loads I look at don't have issues (or the machines I've done profiles on don't tend to show them as much). Hmm. Just re-did my usual kernel profile. It may also be that something has changed. I do see "clear_page" at the top, but yes, memset is higher up than I remembered. I actually used to have the reverse of your hack for this - I've had various hacks over the year that made memcpy and memset be inlined "rep movs/stos", which (along with inlined spinlocks) is a great way to see the _culprit_ (without having to deal with the call chains - which always get done the wrong way around imnsho). Linus