From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 793193858C41 for ; Tue, 5 Sep 2023 17:30:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 793193858C41 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linuxfoundation.org Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5298e43bb67so139097a12.1 for ; Tue, 05 Sep 2023 10:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1693935001; x=1694539801; darn=sourceware.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=L0QJI4bE786c5OvpFNnHFhVYiKCOUh1KvXbEeZnybrA=; b=hrkuOhNVVTpwbF74wfxHgV67OjW/mVauoq6P9b+SddnKMTYF5XKPa4KmtrfQeGnLPl o4t0sGdhHg4OGbdfUi1Rn2Mg4WOe6FMWOlIqzMROIfFGZ3AEzAfWwRU0LSs65xo7rxat WbXeXlEKG7RAymqOKoWA3s4LB6lIvqCSY1SP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693935001; x=1694539801; 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=L0QJI4bE786c5OvpFNnHFhVYiKCOUh1KvXbEeZnybrA=; b=NnZJx262U8dJENWRZYF4D5qB8XZXwGQNlsijGCZtawcFU5Z2C7XwTpbUHECgfPoMOa L+lZVA24iyzyFBczpI7u3xsr3TWF+utojjyy4WHpzPVZpam7YZIqlL7c8iUGN3QmuTmz Q5Kx8piIIMAinO80w0gKjAxb/EqrwbHnbG+/62Cz09m32M3X70QeoOr29AgeVQxbUrmR 0jrEIGKgyGnWu1AbkD27jn6+G/WtX8e0oPkmYCZmEmyMyLSszNOKXyolRxsv4S9+OspH aQLK1SxCWjhao9HFvGj4owIbf7uotORV80k59Ff7jcsNczxcqc9sVVjkeTbprrFH52uB k70Q== X-Gm-Message-State: AOJu0YzAZgfmFAN8hx16glo4j99gJXs+NmAhmK7wScX9xuFwovmwDg63 3BtBvDh6mtHWqNcdoto66aoT/+y4OnAG/nQ/WHxLR0rY X-Google-Smtp-Source: AGHT+IGzgpEhj3S8DRK7RWbe+07Khk51FUCMxwNDZQEmnTF/HwaBwgx8raM4cRfZWFOlGPIJtYowTw== X-Received: by 2002:a05:6402:8c3:b0:522:d801:7d07 with SMTP id d3-20020a05640208c300b00522d8017d07mr543032edz.10.1693935000975; Tue, 05 Sep 2023 10:30:00 -0700 (PDT) Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com. [209.85.218.47]) by smtp.gmail.com with ESMTPSA id b18-20020a05640202d200b0051dfa2e30b2sm7448619edx.9.2023.09.05.10.30.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 10:30:00 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-9a2a4a5472dso12487066b.1 for ; Tue, 05 Sep 2023 10:30:00 -0700 (PDT) X-Received: by 2002:a17:906:30cd:b0:9a1:d1a0:41ad with SMTP id b13-20020a17090630cd00b009a1d1a041admr532347ejb.21.1693934999936; Tue, 05 Sep 2023 10:29:59 -0700 (PDT) MIME-Version: 1.0 References: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> In-Reply-To: From: Linus Torvalds Date: Tue, 5 Sep 2023 10:29:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH) To: Mateusz Guzik Cc: Adhemerval Zanella Netto , Andreas Schwab , Rich Felker , Mateusz Guzik via Libc-alpha Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 5 Sept 2023 at 06:14, Mateusz Guzik wrote: > > I completely agree this is a problem going way past fstat. Realistically, fstatat() is likely the only case that matters from any performance angle because it's the only one likely to be used a lot in real loads. Sure, there are other "at" system calls, but they just aren't important from a performance angle. I don't think we've ever seen 'fchown/fchmod()' be a major performance issue, and if it was, the cost is elsewhere (ie the writeback of the changed inode), so if glibc were to translate it to 'fchownat/fchmodat()' with AT_EMPTY_PATH, it really wouldn't matter. In contrast, there are tons of loads where 'fstat()' is a noticeable part of the load, because the "open+fstat" pattern is simply fundamental Unix code. So converting it to 'fstatat()' is simply *bad*. Right now the kernel does even more than it needs to do (ie it does the whole pathname handling, because I certainly didn't expect AT_EMPTY_PATH to be a *hot* path), but as Mateusz says, even with that all short-circuited (we have a trivial patch to do just that), just the cost of checking "is it actually empty" is noticeable because of the security boundary issue. Linus