Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8243386imu; Fri, 28 Dec 2018 13:32:41 -0800 (PST) X-Google-Smtp-Source: AFSGD/UAMGGoZCc3O05VighcLnzYMmnVfUR1q8kS2OD7YM1QWOz0WAy0HVhhEOuZzdalB3EKjoNV X-Received: by 2002:a62:26c7:: with SMTP id m190mr30040708pfm.79.1546032761310; Fri, 28 Dec 2018 13:32:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546032761; cv=none; d=google.com; s=arc-20160816; b=uWOOKJvYlMzexl4lZnqGiDS6gI20LcOxDniiQ0HSPC/kB9TTndB0V97JEwcByJ0QJp /1l7tPMi2bBtHz8kzG2yvJ9cbRUjKwk7zMozh3KvQntL8D2YweVWbCGlz8SSOemewQ3F fFM1zJk1kA9ZMFBS39LwhmeMApi6ReJZvxpdGaHQIjF1o+TYgatA7VeTuj8OCvDpq2qp U4CYSfGIUQ++Gd3CtmYtc0hIz7sqPu98Cl2J7Npnto90QEz0VnDBftnOxKgpgqKD9/dX GR2YRin9nf36wVi4A6vyPhdRt1EZtONmYqxdbzhojE/ZoGUfZDMwWnFAFJgL5sQ5p1j9 Dniw== 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=GHGQ4SQqJ3S76tOY9ExRgf6A+/dbhmXqV1DK117ES0Q=; b=SSuAteDYEOYr2x/tjXF4zdabiaWzDgzs05lHfOo1JQu+YKXk9hcf5v2z4Odd88tAZF RSpaI9ZRC2hEV/rOi28898xx6Sgm+C3iojRWcKzAKAGK6gGIteCi21Mgf6m/fpLDuEhb e4lmH8uGqU98zTXp+1J5xh3Y1iz03EuOy5a+oPYtgUgjHIiAxfc52NzRQRoKkw5MOk8d ZTFEsHDALLq7PiVr+k9kaRhq3nsp/R9ehoPHodUo5ksLgDwjcYj7kQdSU0DM8aIKowZJ 9KZqWQEnjJ4HsIFFxKUMPnJNys0VKzU0uY1smH2OE1vm+hnoK8sZVjhJ5prXbfFPOq06 jgiw== 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 b6si33652111pls.367.2018.12.28.13.32.26; Fri, 28 Dec 2018 13:32:41 -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 S1726280AbeL1MBr (ORCPT + 99 others); Fri, 28 Dec 2018 07:01:47 -0500 Received: from albireo.enyo.de ([5.158.152.32]:55164 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725889AbeL1MBr (ORCPT ); Fri, 28 Dec 2018 07:01:47 -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 1gcqpj-00055y-Hp; Fri, 28 Dec 2018 12:01:43 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1gcqpj-0005cP-Fb; Fri, 28 Dec 2018 13:01:43 +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, 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> <87k1jtvp8u.fsf@mid.deneb.enyo.de> Date: Fri, 28 Dec 2018 13:01:43 +0100 In-Reply-To: <87k1jtvp8u.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Fri, 28 Dec 2018 12:56:33 +0100") Message-ID: <87ftuhvp08.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 * Florian Weimer: > * 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. Ah, right. If struct dirent is 64-bit only, then the d_off member will be 64 bits as well. But it is unclear whether you can use that with lseek (probably yes, in its 64-bit variant), and it's unlikely it's going to work with seekdir because of the POSIX-required long int type.