From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 49C543858D32 for ; Tue, 5 Sep 2023 13:02:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 49C543858D32 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-ot1-x32f.google.com with SMTP id 46e09a7af769-6bd0a0a6766so1826231a34.2 for ; Tue, 05 Sep 2023 06:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1693918923; x=1694523723; 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=ERiE+UzgahzUkxyoobLukpfwMJuXoSJmUqzyDWMjt+0=; b=D90PpESaBUo1+1w8mFGX0VkFerIgy/PFJ98saxjxu4nn6/Oc4lRBMHZizGvdxzUO5+ NVIBZ/donGwdG5+4GC+wQrY46necvUeh1H7weS67q2XlErKGN00UFQBy+vucUTIte/n2 XZhEW0MJrIhWt9qAcxNiBwwb7V8D958c7wGiWTh1dtf7PqhejKlwFisEzUJQ+5w5YLhX KdXdvT8Wa7oPzHPkghe/8VcQNJBj8IRetIq650wUJfugJ4zJ4J8tA7nzaG9GBz4DnPV9 epLiSNY88RpG1FUwmliBZnsIQHg9tkBS0sWzKSjNxEK+aOLSrOOZWu9ijDscRrmXtlLX mMwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693918923; x=1694523723; 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=ERiE+UzgahzUkxyoobLukpfwMJuXoSJmUqzyDWMjt+0=; b=b1X85RJ7Zl9h6nvcMJUApw3gRQPqanhSLgpcB8GHDOybsO9uSSPRO6/HM6O61aGWR9 9xx0KLg9EJh4tcKolnBtfKgDR+Ymbk/EwnuxyeczcJqA9c0CMPQUx/3jB5kfpYMyTNzp 2USkGW8cRRcP2vgXbCHcLxC+RXS4Sflw6p7+PVSfELWdAgn046NWqRGHt9mi+A5RD5Vb XvQ84XG9Qgj1qkvEs45oiKYCkpny+Ip0GoTZGYz0mCV1r6DbKoHQJOnXtY7VC+5VilkY Vk4/cYFQwyzYbG52i9QwEUXNSJu1o3eHAY/0EOMH7Nfd+aRPveijRMFNiUl+vmM/do8W OviQ== X-Gm-Message-State: AOJu0Yx7ZZD5wj/6MAPvhbsjy36UPeE76CHrN9xGrK2G0IoGTJcXCnWj 8nZNVimBH4urdi7luQSuom19hDFfie1OQ6Ok/d82eA== X-Google-Smtp-Source: AGHT+IEW/e89S/KFdIqIXxB19suvzYKztlksf48rUcRybl18zvzsny7Ci20BJZOxQL+zOiXKPSueRA== X-Received: by 2002:a05:6830:12d3:b0:6ba:865b:ca72 with SMTP id a19-20020a05683012d300b006ba865bca72mr13398734otq.31.1693918923412; Tue, 05 Sep 2023 06:02:03 -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 a18-20020a05683012d200b006bee542e840sm5441458otq.1.2023.09.05.06.02.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 06:02:01 -0700 (PDT) Message-ID: <680b330d-6ef3-adc5-9ba6-cf74dd53e422@linaro.org> Date: Tue, 5 Sep 2023 10:01:59 -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: Mateusz Guzik , Andreas Schwab , Rich Felker Cc: Mateusz Guzik via Libc-alpha , Linus Torvalds References: 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 04/09/23 07:11, Mateusz Guzik via Libc-alpha wrote: > On 9/4/23, Andreas Schwab wrote: >> On Sep 04 2023, Mateusz Guzik via Libc-alpha wrote: >> >>> Commit 4d97cc8cf3da ("io: Remove xstat implementations") reimplemented >>> fstat entry point on top of newfstatat (as opposed to newfstat). >> >> You are looking at the wrong commit. See 30f1c74394 instead. >> > > I still got the right person and the question stands. ;) > The glibc has started to implement some symbols over more generic syscalls because it simplifies *a lot* the required code (just check how messy was the stat family implementation back then). So I would really like to avoid the need to get back on arch-specific syscall to fix very specific corner cases. If I understand correctly, the issue seems to be the usage of a empty string sentinel ("") to indicate the argument it not really used (which trigger all the SMAP issues since kernel will always try to copy the argument from userland). This also means on x86_64 you will also have this performance penalty on syscalls that use AT_EMPTY_PATH (i.e, execveat, name_to_handle_at, open_tree, faccessat, etc.). I really think it would better fixed in the kernel instead of adding extra constraints for the userland. CCing Rich, from musl, which seems to be also affected it and to have another view from a libc implementation.