From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 27E023858D38 for ; Mon, 11 Sep 2023 22:10:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 27E023858D38 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-x32e.google.com with SMTP id 46e09a7af769-6bf298ef1f5so3555011a34.0 for ; Mon, 11 Sep 2023 15:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694470239; x=1695075039; 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=gIwZreb2VVwfnP8ZtRd8N/MGBPh7QKI1kl1hX0eI3Tg=; b=Tl2whnElYWUt4re6RgnatceYsUv2vm4nUaXqsL7w+MhhKftXLGuftYnoT5kg8aO6xI PcVsiRfUA9aBoLRkNPP8adDl/mPdvHvyQnW08O5k5UbfdiNRYUycuJxcoAbc79z2EnTu UrAZs5DaukETJa1aLTf8kipG/epBuD1QfSoKTmJZRoVuNjf7YFRL3GigYrl/Ulkyn3r2 LhBZA4Ak0pzaasGJGBUenrP/MVPha+B8lV8UweXYhskM+og8C9/1qJeBcLzOSQzCqC0A HEZ4cPhRpM9byXI/H0rZPEOMebRLJRv/SbVCxbOkK3228H7x4D9OR5bM07JYAkofHzE6 0lhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694470239; x=1695075039; 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=gIwZreb2VVwfnP8ZtRd8N/MGBPh7QKI1kl1hX0eI3Tg=; b=nq3KfLEyDYrWsoT4xgYwWiG+FWpOLz6zZxQdznd7Yi/M/fxgtpAcTk4+wqgZv2j+1H q2llYL+hCRAdt6RRXtyUGXwfEjp1yMQ33B3qHRyhsJiTMrnePJMrUDlxG5bu1WsYzT1+ Wlaz+coG9lF2iT9vBS0OXrvznhg+iXaMo+QA7mtqUZpDHhIracAH002RKAF2JpnU7mWQ L8ZqTmxgU0bTH+xLMumAUbLrZmMMvIIFdtz8ofVJ0yYNozPqr3FsaPV2HtyHLUkyu3bW YsO5CtNhFFmqtzXwdRLA2JdSH3eKBZHZhBzUV8ctVFePqxbwG2Y1nHb3HBG6qUzxo9ow IvYw== X-Gm-Message-State: AOJu0YwKh/+wo5wtWtJfF22spRC8FEMJK2MvBCq+EOShsCWNyTrTlIXg Py0eT0juUCmbB9Oix5cv43NvEA== X-Google-Smtp-Source: AGHT+IFkRYKWnLUzbV7bOAZTiejvofh/Bo48DLchMJb7zb7vKvmn6PFusdI8gTLxb3ZKX3RHYZmBbg== X-Received: by 2002:a05:6830:1da9:b0:6bf:df:66d5 with SMTP id z9-20020a0568301da900b006bf00df66d5mr10647183oti.35.1694470239410; Mon, 11 Sep 2023 15:10:39 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:91cb:1977:7e4f:e638:7fad? ([2804:1b3:a7c0:91cb:1977:7e4f:e638:7fad]) by smtp.gmail.com with ESMTPSA id q64-20020a4a4b43000000b0057377b1c1c8sm3786639ooa.24.2023.09.11.15.10.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Sep 2023 15:10:38 -0700 (PDT) Message-ID: <25e6248a-ec47-71c3-680e-d7ab6fb80cba@linaro.org> Date: Mon, 11 Sep 2023 19:10:35 -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: [PATCH] io: Do not implement fstat with fstatat Content-Language: en-US To: Linus Torvalds Cc: Florian Weimer , Adhemerval Zanella via Libc-alpha , Mateusz Guzik References: <20230905203421.2127750-1-adhemerval.zanella@linaro.org> <87ledjxc33.fsf@oldenburg.str.redhat.com> 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=-7.1 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 11/09/23 16:32, Linus Torvalds wrote: > On Mon, 11 Sept 2023 at 06:11, Adhemerval Zanella Netto > wrote: >> >> I used the same fstatat logic, but using __NR_fstat should be fine. > > I think you should keep using the same logic as in fstatat(). > > Using "#ifdef __NR_newfstatat" basically checks for "not stat64". > > So, for example, x86-64 (and x64) have __NR_newfstatat, but 32-bit > i386 has __NR_fstatat64. > > Now, maybe the other tests effectively already capture this (ie I > suspect FSTATAT_USE_STATX may already be the thing that makes 32-bit > i386 different), but I do think it's actually better the way it was. The FSTATAT_USE_STATX already handles it, and there is a explicit comment later at !FSTATAT_USE_STATX for which ABIs are affected regarding glibc support. So either way (check __NR_newfstat and __NR_fstat) should be ok. > > ... except maybe a comment somewhere? And maybe it might be good to > actually make this "struct stat64" vs "struct stat" more obvious. > > Linus