From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0C28C432C3 for ; Wed, 27 Nov 2019 20:52:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 909C221847 for ; Wed, 27 Nov 2019 20:52:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=rath.org header.i=@rath.org header.b="UqD+YE72"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="vJwGywUm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730593AbfK0UwW (ORCPT ); Wed, 27 Nov 2019 15:52:22 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:51515 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730596AbfK0UwV (ORCPT ); Wed, 27 Nov 2019 15:52:21 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C6A41227BA; Wed, 27 Nov 2019 15:52:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Nov 2019 15:52:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rath.org; h=from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type:content-transfer-encoding; s=fm1; bh= V0nvbw8WupJOsKEB+UWGp4IdWzQhYIZ2S+3nnXpSNeU=; b=UqD+YE72uKeDOGtV J88ybhO5cDKXxNtFffy8Q2AaN67/FbopNXNFhSrHrBcAuj2d68lhRns1ioPqOqok a1mQtbgmC/E8zALXGD84+5Q6VXbPKT8rbwT3EXTo+MDkFvbghGmNQ4hh7dem14cG 9f+0fFtpZ0bhdkb+harmobbShWkYc4+BoVi5NOiXNoaWSqqgw+pXdo2MaR2uTZnM mA/j4qVusHv2Oa5HR4McOiIuW4GoC4CEAsoFfFhtp6HjjoWAn6ULFVjguj3GWfQt KmBu5jIps6WEiod/L2GL5dYaILnJ8787786qGdWNnzzYIxy2MAGsw+46A2Jpktt9 C3fWiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=V0nvbw8WupJOsKEB+UWGp4IdWzQhYIZ2S+3nnXpSN eU=; b=vJwGywUmenFrYeVTix8SPcSQe15Ch7li2MGJzWIEVxmlvCulWsp5Fzdtj eixLX6i5lXX1SuJeP4KmSaCvttdMm+4fjlpw5pqJbpHe9dsgYCwt7SNpCgbwY1EN k90soD+/BepH5jAzG9YJ1puCU0CA4zui7qMOo3thQcBc1IXeZe6XXjUNJaHH6N0H qzANaFzh0N2TxcBZXG9NA1Ji9yayQCuqiSEtkF8MW8eOu1MhL9n643OdFS5ljtky GVBfMeuUoh+CLSFx1DtU85mT1w3Je0562oLjYCqJXT4OIMPAZcmZOHZMJWu3NbY2 eecC0OurqY0XLoS9PZknv8cIu67pQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeihedgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufhffjgfkfgggtgfgsehtqhdttddtreejnecuhfhrohhmpefpihhk ohhlrghushcutfgrthhhuceopfhikhholhgruhhssehrrghthhdrohhrgheqnecukfhppe dukeehrdefrdelgedrudelgeenucfrrghrrghmpehmrghilhhfrhhomheppfhikhholhgr uhhssehrrghthhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from ebox.rath.org (ebox.rath.org [185.3.94.194]) by mail.messagingengine.com (Postfix) with ESMTPA id DF1B83060060; Wed, 27 Nov 2019 15:52:19 -0500 (EST) Received: from vostro.rath.org (vostro [192.168.12.4]) by ebox.rath.org (Postfix) with ESMTPS id E6EB945; Wed, 27 Nov 2019 20:52:18 +0000 (UTC) Received: by vostro.rath.org (Postfix, from userid 1000) id AFD63E1E90; Wed, 27 Nov 2019 20:52:18 +0000 (GMT) From: Nikolaus Rath To: Miklos Szeredi Cc: fuse-devel , linux-fsdevel Subject: Re: [fuse-devel] Handling of 32/64 bit off_t by getdents64() References: <8736e9d5p4.fsf@vostro.rath.org> Mail-Copies-To: never Mail-Followup-To: Miklos Szeredi , fuse-devel , linux-fsdevel Date: Wed, 27 Nov 2019 20:52:18 +0000 In-Reply-To: (Miklos Szeredi's message of "Wed, 27 Nov 2019 15:30:30 +0100") Message-ID: <87muchyrct.fsf@vostro.rath.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Nov 27 2019, Miklos Szeredi wrote: >> Is there a way for a 64 bit process (in this case the FUSE daemon) to >> ask for 32 bit d_off values from getdents64()? > > Looking at ext4 d_off encoding, it looks like the simple workaround is > to use the *high* 32 bits of the offset. > > Just tried, and this works. The lower bits are the "minor" number of > the offset, and no issue with zeroing those bits out, other than > increasing the chance of hash collision from practically zero to very > close to zero. > >> Would it be feasible to extend the FUSE protocol to include information >> about the available bits in d_off? > > Yes. > > The relevant bits from ext4 are: > > static inline int is_32bit_api(void) > { > #ifdef CONFIG_COMPAT > return in_compat_syscall(); > #else > return (BITS_PER_LONG =3D=3D 32); > #endif > } Thanks for the quick response! Is there a way to do the same without relying on ext4 internals, i.e. by manually calling getdents64() in such a way that in_compat_syscall() gives true even if the caller is 64 bit? Best, -Nikolaus --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB