From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id A86FB3858C41 for ; Tue, 5 Sep 2023 17:45:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A86FB3858C41 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-x52c.google.com with SMTP id 4fb4d7f45d1cf-52889bc61b6so3842007a12.0 for ; Tue, 05 Sep 2023 10:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1693935935; x=1694540735; 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=KNGkGXjU309QDe8JBz52g//0mhgs2k9RZjzJ/pof4Ac=; b=MALziaYS4+u3kwSz3IetJb4h94JTOJBhC6vJI5timekXNRvjJhMephjeoF9YS/qAPW JDHF6BufHrkLJQso3rWjKcBJq7fDKQjMCcJ8YSSLr+An0q6CE3uoLVE8atVs2OZI/Csv 7rGzWfnmhqpxt7NdVf6gj+eNCqKpuUBecQhfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693935935; x=1694540735; 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=KNGkGXjU309QDe8JBz52g//0mhgs2k9RZjzJ/pof4Ac=; b=fAVdNxgr4FKQ3sv9dPWdWuE17keqkmIe/ko5C5UicnG6Mj8q6wBXAHpxwGR/oDh4BA tsmi115+JLamE8Gff7Enhw4ZkPrC1zGdt5LHX7VyIAUb8cwaoFvVfwam0KHFuZJpdPmX sP3RhBIQO0HmXGlMlXq3p6MqrS2AqpaDqGx+WerQRDIjPi3xjCB99U4O8gLFqwndx2vq VLCKrL8qyGo6llLhfxtKz3LLfq6IxYkRDLUl8AFIFvyqgRqe6CqEcq98R+8fAcXXkbLE bfHugmcN1coiJ/vprh6v78JurPxMDdFBYygyK9Z+JRmOk13V6KcMGqqqzQLEAm3w2KCC waEA== X-Gm-Message-State: AOJu0YwTjGMfsR7aPogF4GXXGQNJIqGF21w2Bq6W+2e5nlhCX0SQaFnF P9KwC6hBP/J4IzOVYA3GT5BnAfc/7Q2ggiIq1mzoTaNw X-Google-Smtp-Source: AGHT+IH32k44kyhDGbPfc/TQLr7dSw6ixYwnL/eLJjzWPTBFwt5dy7lEebP+O50F3iTfZ+Bv/GjBHA== X-Received: by 2002:aa7:d159:0:b0:522:2ba9:6fce with SMTP id r25-20020aa7d159000000b005222ba96fcemr430098edo.8.1693935935070; Tue, 05 Sep 2023 10:45:35 -0700 (PDT) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com. [209.85.218.49]) by smtp.gmail.com with ESMTPSA id l6-20020aa7c306000000b00528dc95ad4bsm7268054edq.95.2023.09.05.10.45.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 10:45:34 -0700 (PDT) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-99c136ee106so428444266b.1 for ; Tue, 05 Sep 2023 10:45:34 -0700 (PDT) X-Received: by 2002:a17:906:31c3:b0:9a1:af6f:e373 with SMTP id f3-20020a17090631c300b009a1af6fe373mr416173ejf.42.1693935934280; Tue, 05 Sep 2023 10:45:34 -0700 (PDT) MIME-Version: 1.0 References: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> <6d0e4e9e-ab69-0c73-bb9d-ce344b4a043b@linaro.org> In-Reply-To: <6d0e4e9e-ab69-0c73-bb9d-ce344b4a043b@linaro.org> From: Linus Torvalds Date: Tue, 5 Sep 2023 10:45:17 -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 10:28, Adhemerval Zanella Netto wrote: > > I think we can still make it in a generic way, stat family would use more > syscall (which some filters might complain) but it should be ok: Ugh. That patch of yours certainly seems to avoid the kernel overhead (where that "fetch a byte from user space just to check it is '\0'" is much more expensive than it is in user space), but why does glibc do that whole "turn fstat() into fstatat(), and then turn it back again"? It seems just stupid. If the user asked for 'fstat()', just give the user 'fstat()'. Your patch literally adds *complexity*, rather than take it away. Is this all just because glibc did its own 'struct stat' implementation way back when, and you want to have just one place where the stat conversion is done? Can't you just special case *that* case instead? It's long been irrelevant. Afaik, on 32-bit x86, you just want to use the 'stat64' system call family, and on 64-bit x86 you just use the regular 'stat' family (yes, called 'newfstatat' for that one system call for internal historial reasons), and there is no conversion needed. IOW, all those wrappers just for 'struct stat' conversion are pure overhead and silly garbage. Why do they exist? And if there is still some other reason for them to exist, can't you make that be a 'sysdeps' file of its own, and not penalize all the sane cases with 'copy stat structures around'? Linus