Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8242921imu; Fri, 28 Dec 2018 13:32:06 -0800 (PST) X-Google-Smtp-Source: ALg8bN7J5WtBc5wp/x2F9BRedC49Adm3NTqPlh8OHlEWCXeCEkz4KgeL21/SfsMrXPHkqFWpxkH3 X-Received: by 2002:a63:eb52:: with SMTP id b18mr27117995pgk.213.1546032726360; Fri, 28 Dec 2018 13:32:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546032726; cv=none; d=google.com; s=arc-20160816; b=dMOaTYGzRAijxv4WBFTrFCuBut/iqahSzIBw7EmVgeiX1C7trRXvGHfVwOCk8QR7BY PeC3gR22/fmV96sFwbjY3seYutdUVIMu8P8lBM4A/kRXJWGwqqBFfruvYr7nth14nk// lm+NFT38jANPukLg6pErkHXEHzzVsg11vugQylsvhg32Om9fWJZ3fusrH8vSRywC0Wc8 IX8hcwslqmMiGA7AU3EfziL0FBsHDezepFum7yBinyxO3lmjgfII96km2duX8pfatKCW TRvRFTbKqFEGWBwpNCUCVlnejzu2PZJ9TtwCI42Yr1EKvCzhZKX+pK6yXd43eGpoFD5v eV5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=vjFKkbWWgBhpxDX7i07vC2gdE4so1js3PoIyR+MZ5iA=; b=G8uufUplCERGN2zN/PraqI1ecEeTxOgODusjtiVONvxyWU/mfuy68+9ntcdTFVdhFX ccHvRQ/v3SN9ntruQ1n47v2ad4a5KPdJAT6g8ihZYPfXejk11rbXS+A9xPd1k4adX2W+ x0s3rWbuH66KBc1KW/9u2YS/+CoYHC7ITnrYSOKm9PEPdraGa9zWpBzGPtOZcARfulq4 h5OzPWKHiiaqZEetvhRT9buBEc/t5dREjWjD4Dg8QaQujYq64UK27A8rlN7aUkM4QJK1 ecFoEDYS9eOzwHvjxN59BBuNS/ovxDKbFSkheo8Jz2mfxtixbO4HefAchLXdGDsvSzG5 yscQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay7si17175671plb.410.2018.12.28.13.31.51; Fri, 28 Dec 2018 13:32:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730971AbeL1L4i (ORCPT + 99 others); Fri, 28 Dec 2018 06:56:38 -0500 Received: from albireo.enyo.de ([5.158.152.32]:55106 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727027AbeL1L4i (ORCPT ); Fri, 28 Dec 2018 06:56:38 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gcqkk-0004t9-28; Fri, 28 Dec 2018 11:56:34 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1gcqkj-0005XI-TM; Fri, 28 Dec 2018 12:56:33 +0100 From: Florian Weimer To: Adhemerval Zanella Cc: linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, libc-alpha@sourceware.org, qemu-devel@nongnu.org, ericvh@gmail.com, rminnich@sandia.gov, lucho@ionkov.net, hpa@zytor.com, arnd@arndb.de Subject: Re: d_off field in struct dirent and 32-on-64 emulation References: <87bm56vqg4.fsf@mid.deneb.enyo.de> <957967d7-5717-8ada-fb30-dfdf19898b6b@linaro.org> <87pntmu9iw.fsf@mid.deneb.enyo.de> Date: Fri, 28 Dec 2018 12:56:33 +0100 In-Reply-To: (Adhemerval Zanella's message of "Fri, 28 Dec 2018 09:53:21 -0200") Message-ID: <87k1jtvp8u.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Adhemerval Zanella: > On 27/12/2018 16:09, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> Also for glibc standpoint, although reverting it back to use getdents >>> syscall for non-LFS mode might fix this issue for architectures that >>> provides non-LFS getdents syscall it won't be a fix for architectures >>> that still provides off_t different than off64_t *and* only provides >>> getdents64 syscall. >>> >>> Currently we only have nios2 and csky (unfortunately). But since generic >>> definition for off_t and off64_t still assumes non-LFS support, all new >>> 32-bits ports potentially might carry the issue. >> >> For csky, we could still change the type of the non-standard d_off >> field to long long int. This way, only telldir would have to fail >> when truncation is necessary, as mentioned below: > > I think it makes no sense to continue making non-LFS as default for > newer 32 bits ports, the support will be emulated with LFS syscalls. Sorry, I don't see how this matters. seekdir and telldir are NOT affected by LFS.