From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id E26703858D28 for ; Tue, 5 Sep 2023 19:22:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E26703858D28 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-ej1-x62c.google.com with SMTP id a640c23a62f3a-99c93638322so37253066b.1 for ; Tue, 05 Sep 2023 12:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1693941726; x=1694546526; 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=vvSBUqFF/1FK0DhQyDKlSu2Di88NW7en7r/XQxzRFqY=; b=B24WtNx21PzcWjluR0mDt9nvA11s6sXuP/3uHXwlgkfsmQRa6vDw7VdeGBSv/JGJ45 RK9IcfumOwXV9R9LTTlSRHpauYmVyzZJfnn8HDmH5Y6/C3PLjQqfFrPK2X7d02oAuIkj uFIgPw95pYbnKS7aHfLx2Pzz8UgE7ZQC9QWXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693941726; x=1694546526; 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=vvSBUqFF/1FK0DhQyDKlSu2Di88NW7en7r/XQxzRFqY=; b=ATT5wcMKxbjPFpd7mJjok9OsgoaUff/P+VFt6WXGjuxOO9J68kJk4xnhKaE6gAqOoO JLAsvGIEClEQ/Z6nU8tT8N+QDnzMwi1GInjtT9XGvP2P0swSS5D36IRinO0JZu5PqIw9 t3MBCu0Mlo/fZbER0VCEBBIe3zXLFSKvOxrgkZ1SNllaSU2BhASWAAV11844kR6mI8wp qzOeYM0svpk9NI0m8mCnxUxyRDI4tDI+0ECfeWVzKsdqXulqNclb/vxXa20wAmR7nGOj MER3p9E9p/Zw1KqB2WHGFIoES38G3rUwLnMau6BdoMtplL+nq52SCuD7Sm0uWzDk4sPZ Tohg== X-Gm-Message-State: AOJu0YwQKL+nGWU0QpBCKLyugYDpKzTh2kaMYX7y3wIkCtIx5P6FUXNf ahIu8LoU6hE4MdsGFs4PqXzkVJuxfAIGHp/Lf2V4epkC X-Google-Smtp-Source: AGHT+IGuccIt6N5gX2KWtJUjfICkb5ySDX3aAvBtALDRtfytShSF01hIksg6Ajh3r2CUtyVw7n/q4g== X-Received: by 2002:a17:907:2be1:b0:9a5:d2c6:c58f with SMTP id gv33-20020a1709072be100b009a5d2c6c58fmr694146ejc.24.1693941726308; Tue, 05 Sep 2023 12:22:06 -0700 (PDT) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com. [209.85.218.54]) by smtp.gmail.com with ESMTPSA id dt22-20020a170906b79600b0099d959f9536sm8095427ejb.12.2023.09.05.12.22.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 12:22:05 -0700 (PDT) Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-9a1de3417acso40134066b.0 for ; Tue, 05 Sep 2023 12:22:05 -0700 (PDT) X-Received: by 2002:a17:906:3152:b0:9a2:26e4:a5e2 with SMTP id e18-20020a170906315200b009a226e4a5e2mr802777eje.25.1693941724849; Tue, 05 Sep 2023 12:22:04 -0700 (PDT) MIME-Version: 1.0 References: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> <6d0e4e9e-ab69-0c73-bb9d-ce344b4a043b@linaro.org> <387426d5-17c8-cf3e-83a1-88b55c9d22a1@linaro.org> In-Reply-To: From: Linus Torvalds Date: Tue, 5 Sep 2023 12:21:47 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH) To: Adhemerval Zanella Netto Cc: Mateusz Guzik , Andreas Schwab , Rich Felker , Mateusz Guzik via Libc-alpha Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 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 12:17, Adhemerval Zanella Netto wrote: > > Below it is the stat logic implemented directly on stat64.c code. I was looking at that exact thing and going "if this just had FSTATAT_USE_STATX it would all work easily". You seem to have fixed that by just moving the FSTATAT_USE_STATX logic into a common header file. IOW, this looks good to me. > It avoids > the "flag == AT_EMPTY_PATH ..." check, but it only handles LFS calls > where statx is not required (so 32 bit architectures will still continue to > use statx, but I don't think this would be a problem). I think that given the existing logic, that's exactly the right thing to do. Let's face it, 32-bit is getting to be pretty irrelevant. Thanks, Linus