Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3695786ybh; Tue, 17 Mar 2020 05:01:25 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtVbB7Li8vMja25kfOnTpeZ+mS57880bxydDxeQkopWs9X1ibBciX845MzUX58nY0fPRi2m X-Received: by 2002:a05:6830:134b:: with SMTP id r11mr3095811otq.305.1584446485772; Tue, 17 Mar 2020 05:01:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584446485; cv=none; d=google.com; s=arc-20160816; b=ANLmGrXuEgWqimxlOAA1hilpxqtevRsJ/lEK3ANHzR2Ex9V/ZLDaAwwcq4JfppzgF9 zhKEB5ivsPAD4tRKCi4uqs1xOFIIv5ijdVNpGH7EjMXINQ2EkYg09WkxiImydlfKlMZJ +iraNZf/AfVB6t0lpxrk2EHJsZijA4lJO0cf+AzXrpbxKdO04GOzzG6c6HUT5r9NoeVN PuPxsyQj2PIbULbQzqHJYoAyRNNTNRYkm8xEgDEIvf2bJGWZw7fdyJ3OxXy/fy34xXai ektIdNROynpPmOtV7ROtRhIaLdr9Vqgwfi89Yhw3dI71rmDU8FX018P4We1gqa+mtLqR hDSQ== 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=n0pmJfRSy5K7C7B/Dj0KYF1FSkvyqnuxlXYMQVWra6Q=; b=rkbJ64KCA61uCbASQP1flqk1pvbyT4w3FyvFa0o1xH80++p7XLJzS7Af+8tApRIYy8 PKKmX0yzjENjfXZaaF+lGKXek3dNJQtKnv7Xr2Z3DyJzOr8FhgrmVIpmkC4Vws9FyjcI H/KZ0yMmUBbfZvYyYr0Yep3p4oWk9O11E75EecOIL93MBB6GapyLWqm9Ue5+o1f/AziF Y/RhxgVznacZ+iGyJje7Hkm/vsNk3a/GKDVYQu2puVuNimzHf0cbKOMywW98lM/F28ir +hDAsH4RK/U8NwXJXhyREtX7SSCJku0CNHL5Ik82+17LZQdb2ZF3bNCKWw9cmWalYrks fFtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 v81si1657683oia.114.2020.03.17.05.01.13; Tue, 17 Mar 2020 05:01:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726428AbgCQMBC (ORCPT + 99 others); Tue, 17 Mar 2020 08:01:02 -0400 Received: from albireo.enyo.de ([37.24.231.21]:50338 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725872AbgCQMBB (ORCPT ); Tue, 17 Mar 2020 08:01:01 -0400 X-Greylist: delayed 446 seconds by postgrey-1.27 at vger.kernel.org; Tue, 17 Mar 2020 08:01:00 EDT 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 1jEAmp-0003yE-1g; Tue, 17 Mar 2020 11:53:31 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jEAlQ-0004mu-4A; Tue, 17 Mar 2020 12:52:04 +0100 From: Florian Weimer To: Linus Walleij Cc: Theodore Ts'o , Andreas Dilger , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Peter Maydell , Andy Lutomirski , stable@vger.kernel.org Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes References: <20200317113153.7945-1-linus.walleij@linaro.org> Date: Tue, 17 Mar 2020 12:52:04 +0100 In-Reply-To: <20200317113153.7945-1-linus.walleij@linaro.org> (Linus Walleij's message of "Tue, 17 Mar 2020 12:31:53 +0100") Message-ID: <87lfnzdwrf.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org * Linus Walleij: > It was brought to my attention that this bug from 2018 was > still unresolved: 32 bit emulators like QEMU were given > 64 bit hashes when running 32 bit emulation on 64 bit systems. > > The personality(2) system call supports to let processes > indicate that they are 32 bit Linux to the kernel. This > was suggested by Teo in the original thread, so I just wired > it up and it solves the problem. > > Programs that need the 32 bit hash only need to issue the > personality(PER_LINUX32) call and things start working. > > I made a test program like this: > > #include > #include > #include > #include > #include > #include > > int main(int argc, char** argv) { > DIR* dir; > personality(PER_LINUX32); > dir = opendir("/boot"); > printf("dir=%p\n", dir); > printf("readdir(dir)=%p\n", readdir(dir)); > printf("errno=%d: %s\n", errno, strerror(errno)); > return 0; > } > > This was compiled with an ARM32 toolchain from Bootlin using > glibc 2.28 and thus suffering from the bug. Just be sure: Is it possible to move the PER_LINUX32 setting into QEMU? (I see why not.) However, this does not solve the issue with network file systems and other scenarios. I still think need to add a workaround to the glibc implementation.