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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 79B75C10F29 for ; Tue, 17 Mar 2020 11:58:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4EF6420714 for ; Tue, 17 Mar 2020 11:58:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Mdv9Ev0h" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726278AbgCQL6W (ORCPT ); Tue, 17 Mar 2020 07:58:22 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:42402 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726476AbgCQL6V (ORCPT ); Tue, 17 Mar 2020 07:58:21 -0400 Received: by mail-oi1-f195.google.com with SMTP id 13so12462654oiy.9 for ; Tue, 17 Mar 2020 04:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6tLG0UvowYMxwNr6UXAFjrYE3UP2cWO9OOJLVI6SNuM=; b=Mdv9Ev0hWdBHO5UtWJBB5vCi54nNKxRYMIn7zCsdg1tggsr/dFr1x5TNXD+4ERd0q2 PUoF44Wb4BkSNPkR9ulesNTcwjCkGsbALj4ZupRv8XsmzqWwS5YJXopOOx8syMeK4533 7eJYFQUad/uIAzsDKrZnKv5hZtUuKt17hNXGdkfIJoDgY97TICZViYb6603+aR6OzAIb 2WSTWc2I0/1ENQjAE2ngPZCWMxZ8qIWEyPqceeV2NDusE76aX2/SupifuU1JiiZ96QMT fuESbGTlTjfcLIhal4/lii+GTNk+pVzllv8CdXvcxNo+Wm9dlKrXPl602p7K7WcrqKHS 8gcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6tLG0UvowYMxwNr6UXAFjrYE3UP2cWO9OOJLVI6SNuM=; b=bPjKCFAj2yCrY85s7/itq7Eh8Nat4UBMNa2vtiwbf9HMiUDbIKZDagCnHokY/1lSpc 7tUK8lcmTR884AJJFLxHAcH8OJ6yyKrSYiikvcgXhcMDZ3+6M00YWgTYaPkwv2MH1m6U YqGQrMfeCmD56REVdTN6srH5KjpL/XLBM7xHnoLugrFEEaWX3TjqijevAsuFAnkyi3n+ NVVj6ESq4Mh/FpdbaKlr6Ywzoq5pWjevNNQee01+UiLQiNznS3pvCNnRc8UOvE5NmTt/ zh6q2BBBx8CAeudFWJWQDXa55lEilvsfLfR3UZh/myvjnqOIBiIcTdJThX4s7kHScWWI Jpxw== X-Gm-Message-State: ANhLgQ1O2PIaRb8jH7YA6RwEk7l6xeAQlqJ3vqu1vT1zlXy904NlAPFV eAU4d18y/J+7hoJF0CFtvqHxs9txgAcSyFkH/waqdA== X-Google-Smtp-Source: ADFU+vv2vA2intsubk2Bd6nP5kQhiggirL2UjEzCPX13Y5LB21Ez3zUMdijWMELThsGoCt5RUUEDjjKOmgDyl+5iHeY= X-Received: by 2002:aca:c695:: with SMTP id w143mr3238753oif.98.1584446301315; Tue, 17 Mar 2020 04:58:21 -0700 (PDT) MIME-Version: 1.0 References: <20200317113153.7945-1-linus.walleij@linaro.org> In-Reply-To: <20200317113153.7945-1-linus.walleij@linaro.org> From: Peter Maydell Date: Tue, 17 Mar 2020 11:58:09 +0000 Message-ID: Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes To: Linus Walleij Cc: "Theodore Ts'o" , Andreas Dilger , Ext4 Developers List , linux-fsdevel , Linux API , QEMU Developers , Florian Weimer , Andy Lutomirski , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, 17 Mar 2020 at 11:31, Linus Walleij wrote: > > 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. Thanks for having a look at this. I'm not sure this is what QEMU needs, though. When QEMU runs, it is not a 32-bit process, it's a 64-bit process. Some of the syscalls it makes are on behalf of the guest and would need 32-bit semantics (including this one of wanting 32-bit hash sizes in directory reads). But some syscalls it makes for itself (either directly, or via libraries it's linked against including glibc and glib) -- those would still want the usual 64-bit semantics, I would have thought. > Programs that need the 32 bit hash only need to issue the > personality(PER_LINUX32) call and things start working. What in particular does this personality setting affect? My copy of the personality(2) manpage just says: PER_LINUX32 (since Linux 2.2) [To be documented.] which isn't very informative. thanks -- PMM