From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id F1A273858D32 for ; Tue, 5 Sep 2023 18:22:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1A273858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-3aa1c046659so2068782b6e.0 for ; Tue, 05 Sep 2023 11:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1693938171; x=1694542971; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Nvg2pdk25EhomOSfJbRX6JAkvgyBmvXWu+LChE8kuHM=; b=RIxN8DA+MfRzqWk7/0AMaEle/oGqs2LCndB8xxQ96zTwTs+LWUL2HAEyo9sr/EOEUk JjCPwsnvmmA+g+BLvvvwU3E2pzjz2Xu0jnXpWvoT51K4/AG8FZFs8F77NT7HeP4pgUX3 bMxwXgiaH/mnYGjhnIdcNcn3xjg0LJum2ru/SrrRPTm/1/yT0To0Z8J+2HdKkjRp3cPx VXehSVSmsWnjBkJdLLYLFmI4lOYK3qSrUPwvA+n/KmZmE+wuC9vaGrGIPNxHxyVpQSHH Z0dUVIgrGsvRQwJBEwuz/qzVoW81Qwx3ep0o24x7dCZznbvXKbVm7xCaKaXucEU8dQxX UvEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693938171; x=1694542971; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Nvg2pdk25EhomOSfJbRX6JAkvgyBmvXWu+LChE8kuHM=; b=FxUljq9JBGuEEZC/KTBWq/nL0yXuqQA7ZtLp9/2ba2zWzKGLaSGx15ZPXZulsv7OZU ezyEuaeGvlnkPie+ENRzIbSCEgOAWVWs/tGA5gftz7vZeJpuyKn19SNlXPRC49AU8und Xphq+IwW9xbqgeJpSQymNJ2v2cT+S7n4J3oz6LqGbSgFfGCS3dTDlh72HE1jSxzRJ3aB widLFK/ZgQY7V9ioyMKaZzX6pwLJR+IURbbDWisP4arT9IzrGNHgSgLEhljzBhP3HYdg hIOYmdUwKcRVqFR/EeQ5vbffjtghz2KGOkmDIcSzWpQCCurEV4o61bEurArjrLOu/IiG Ueeg== X-Gm-Message-State: AOJu0Yzl1nsKCbTTV6W7TZSOsSKdO76XApYFQps1HmWRMt1NYs2McGcf K+oQbgqrkhRRgDdfU9Lntw+0tw== X-Google-Smtp-Source: AGHT+IGBsf1k/lSBIod74pjm1TsynLwCRGlPvHHJdavb8T5q/MFPZMcWFbgSfQzVTsExigjDTQWYVA== X-Received: by 2002:a05:6808:1805:b0:3a4:8f16:f637 with SMTP id bh5-20020a056808180500b003a48f16f637mr18067116oib.48.1693938170991; Tue, 05 Sep 2023 11:22:50 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:fee4:a053:a54:7b70:a25? ([2804:1b3:a7c3:fee4:a053:a54:7b70:a25]) by smtp.gmail.com with ESMTPSA id s25-20020a056808009900b003a9baa79051sm6123170oic.11.2023.09.05.11.22.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 11:22:50 -0700 (PDT) Message-ID: <387426d5-17c8-cf3e-83a1-88b55c9d22a1@linaro.org> Date: Tue, 5 Sep 2023 15:22:46 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH) Content-Language: en-US To: Linus Torvalds Cc: Mateusz Guzik , Andreas Schwab , Rich Felker , Mateusz Guzik via Libc-alpha References: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> <6d0e4e9e-ab69-0c73-bb9d-ce344b4a043b@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 05/09/23 14:45, 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()'. > > 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'? The old glibc stat code was a complete mess that was added prior symbol versioning, with multiple implementations, along with a static linkage that defines the current version (there is no need to describe it further). The consolidation also provide a much simpler way to support y2038. On x86_64 and some other 64 bits ABIs where glibc exported struct stat is the same as the kernel, there is no conversion whatsoever. It is only required on some ABI where due historical mistakes the exported user struct does not match kernel (sparc64, mips64) and on 32 bits where the no-LFS support is just routed to LFS interface to simplify things. So the fstat to fstatat approach is a way to simplify the code and put all the required syscall logic only at fstatat implementation. By adding the 'special' case back on fstat.c it would require to replicate all this logic plus when to use statx instead (FSTATAT_USE_STATX), which is far from ideal. It is doable, but not really simpler...