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 B5517C4332D for ; Thu, 19 Mar 2020 15:13:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D1E320CC7 for ; Thu, 19 Mar 2020 15:13:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IObK/vTb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727346AbgCSPNX (ORCPT ); Thu, 19 Mar 2020 11:13:23 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:36644 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727103AbgCSPNW (ORCPT ); Thu, 19 Mar 2020 11:13:22 -0400 Received: by mail-lf1-f67.google.com with SMTP id s1so1941280lfd.3 for ; Thu, 19 Mar 2020 08:13: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=/uotPJyrFZ0V5dJBIBxpoXcAAW/RZupCPGuZpTwdN+s=; b=IObK/vTbu2r1EwtJUxcOkt/weNgwAIs+CHTDvFgznXHZYVnCuvygzfOBa4JLbHT97b W9XtSA7rUSeyqs4nYmn9mTKNKjGB079S+l2sxY3DvKZFnHs93Sb1SYARR39KY1nD5L26 /tKgb1jIfCLitehDbmJwfWQipefcZm7L02maSR1IKYDj3oB3T83NhKnIgOSh9+KEIgNl TKDSLoErLO8Nl1dNdDkofdlbfXby0LIXIuFEbQ7kA4LH+4gbAwq0FBa7ki43wI29SXcr z5XGe0X6erHAQQGBtOyfxylFoG3kI/gx/XwBTVRsH+cX4Pz5xNURnZMmaTjSAEji452K LLvQ== 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=/uotPJyrFZ0V5dJBIBxpoXcAAW/RZupCPGuZpTwdN+s=; b=Lwx4Z0Qm+LRo6B02L23zaM4K8HCqubAWmatYT5o+HBCmK2MWqiWSvzZcYUB5pfO2/W d/YNgHfmO3kU5kXNNPQ65+tJh1+RYoLz+E4DSeFUlps9b2Fztj7N/mHB+vaup5I8+Mu0 LoH81aLbV7B4DYSquwpvqr54zJrxD2HT2F3U2hqEneTnYSAvtn2gyZvqtgBZJpKFyJ1y 0bAAXcgl7DVzDBocsajLBmJRtmY7pmw2zmGbTKRMQ/l+hRVkv6xX40LxwYPV9/z1TE6G lXsvieHotz/giqZgXXnqFKbHrcfdVqCgtohF+5TPCceLm15zFDJ1c7TyX+Gz5kjmMG3G SRBQ== X-Gm-Message-State: ANhLgQ2OMeyfXPD8KSfjEEv2EWo6/awO4qt+ARi6EDxJ+LNoZDyhA1ZK F68WJ6q2YfCIo72tRwkFBsJMaQZvEgQQ2J2u3jf8mA== X-Google-Smtp-Source: ADFU+vu1xSj2mSTjDUg4SXO/2v8/tid2EhIWeZkU86OKVTq9D1e8crqiiKiOF6X8KpVKbvzB2tB2QO5h9YFRavOMQH4= X-Received: by 2002:ac2:4552:: with SMTP id j18mr2475295lfm.89.1584630800987; Thu, 19 Mar 2020 08:13:20 -0700 (PDT) MIME-Version: 1.0 References: <20200317113153.7945-1-linus.walleij@linaro.org> In-Reply-To: From: Linus Walleij Date: Thu, 19 Mar 2020 16:13:09 +0100 Message-ID: Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes To: Peter Maydell , "Suzuki K. Poulose" Cc: "Theodore Ts'o" , Andreas Dilger , Ext4 Developers List , linux-fsdevel , Linux API , QEMU Developers , Florian Weimer , Andy Lutomirski , stable 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, Mar 17, 2020 at 12:58 PM Peter Maydell wrote: > 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. The "personality" thing is a largely unused facility that a process can use to say it has this generic behaviour. In this case we say we have the PER_LINUX32 personality so it will make the process evoke 32bit behaviours inside the kernel when dealing with this process. Which I (loosely) appreciate that we want to achieve. > > 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. It's not a POSIX thing (not part of the Single Unix Specification) so as with most Linux things it has some fuzzy semantics defined by the community... I usually just go to the source. If you grep the kernel what turns up is a bunch of architecture-specific behaviors on arm64, ia64, mips, parisc, powerpc, s390, sparc. They are very minor. On x86_64 the semantic effect is none so this would work for any kind of 32bit userspace on x86_64. It would be the first time this flag has any effect at all on x86_64, but arguably a useful one. I would not be surprised if running say i586 on x86_64 has the same problem, just that noone has reported it yet. But what do I know. If they have the same problem they can use the same solution. Hm QEMU supports emulating i586 or even i386 ... maybe you could test? Or tell me how to test? We might be solving a bigger issue here. Yours, Linus Walleij