From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id 601F03858D28 for ; Tue, 5 Sep 2023 21:46:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 601F03858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1c4cf775a14so2321883fac.3 for ; Tue, 05 Sep 2023 14:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693950381; x=1694555181; darn=sourceware.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9tra0nRnptZAxztx6X+fJNImUg5R+MCDi3+sSBjPjP4=; b=oy1sWbUPhMwGAfw6kgj7hyomJ2blZfXwnTdqbNV8xJrcBPgHezmc0TwDw6UAQAZExZ xWAIcFq4Av3j0sbtLm/6KmRNwAGY9012luwpZGOIkR1D2pAJAkNNQG7YsH07MGSjCh6X NC1oGVh4aSjLK/v30qK8lY5WokSXu7zy2E166Pa37c3UzqjaFYvggaQAefa2Dm/E0tUG ADevUAgjOogQyyEXHPQ+nCtgxXTmJY+LVna/kDrmOqKxkSepl9cvQ8s+uf5tj7AuMwMy GTizv0O8q3naKT7tZq9KuLj3YnFZyK6k+eSuF3rt+sGfVfusVoZVEfT7PXn0FPqZm+YL NIdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693950381; x=1694555181; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9tra0nRnptZAxztx6X+fJNImUg5R+MCDi3+sSBjPjP4=; b=F9zO9cyE7VEIkSz9LhL6qT1gz9YGsF2qpHqvBL3LKWnJlJpW9170X/amZaECSDE860 GbdjP8pP7RQcExW1O2716Pdw2nufp5ZQq1xNkrMCIFRD3zGJBqTb+k2WasCBJeA4GY7r OyyRe/DdjgcmC/N/NVGn0i37gTD7lN7q/KWcBV4Jc8zkmHmjtv3vfMz91OKmv6gHNNqW DbfSZOehQLX7T0GDoZtNouFLheH0qHWnFhfljFZi5syHlpg+ThJq0Hh6FfIdZxH3T0yh 5VUkDk0Jl9m7VRzYBMiS4yxL8+TWtppH5nZXOTHA+9WNSrzNN0j1iDM4xr+q7wd3WXu1 B4iA== X-Gm-Message-State: AOJu0Yzqy7ED7yFbt7pAGMNNmG17PnmRl4VOJP/4ck7RY4yHJqRS9AlI mY9qN2krM9r4qHeIBu7Mrb7z6w3u1US2yZwC9UCvydBk X-Google-Smtp-Source: AGHT+IEt3WHGOj6ztwh/04nLaOeFNyhK9hARiZcuGltFw5Rmn4SaCuMsYa/z7OjQtYEgstqW/AVxlWLFjgN3BN6lSwo= X-Received: by 2002:a05:6870:b520:b0:1b0:60ff:b73f with SMTP id v32-20020a056870b52000b001b060ffb73fmr19028631oap.8.1693950381620; Tue, 05 Sep 2023 14:46:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:745a:0:b0:4f0:1250:dd51 with HTTP; Tue, 5 Sep 2023 14:46:21 -0700 (PDT) In-Reply-To: <20230905214242.GJ20403@brightrain.aerifal.cx> References: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> <6d0e4e9e-ab69-0c73-bb9d-ce344b4a043b@linaro.org> <20230905214242.GJ20403@brightrain.aerifal.cx> From: Mateusz Guzik Date: Tue, 5 Sep 2023 23:46:21 +0200 Message-ID: Subject: Re: fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH) To: Rich Felker Cc: Linus Torvalds , Adhemerval Zanella Netto , Andreas Schwab , Mateusz Guzik via Libc-alpha Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 9/5/23, Rich Felker wrote: > On Tue, Sep 05, 2023 at 10:45:17AM -0700, Linus Torvalds wrote: >> 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()'. > > We do it in musl, but we also do the "turn it back again" in > userspace. musl's __fstatat_kstat checks if AT_EMPTY_PATH is set, and > if so, calls SYS_fstat. I don't see why glibc couldn't do the same. > > However, we don't do this, and this does not seem to be possible, in > the case where statx has to be used (32-bit archs). Is there an > analogous issue for statx? > Yes and *currently* statx does not have a way out, but I'm going to propose some patches to Linux about it in foreseeable future. -- Mateusz Guzik