Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201004032536.1229030-1-krisman@collabora.com> <20201004032536.1229030-10-krisman@collabora.com>
In-Reply-To: <20201004032536.1229030-10-krisman@collabora.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Wed, 7 Oct 2020 17:07:37 -0700
Message-ID: <CALCETrVVii5+d1xDiFX03wdS1XhxmezemhHTG7FArF50uVAJRw@mail.gmail.com>
Subject: Re: [PATCH v3 09/10] x86: Convert mmu context ia32_compat into a
 proper flags field
To:     Gabriel Krisman Bertazi <krisman@collabora.com>
Cc:     Andrew Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Christoph Hellwig <hch@lst.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Robert Richter <rric@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Christopherson, Sean J" <sean.j.christopherson@intel.com>,
        kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Oct 3, 2020 at 8:26 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> The ia32_compat attribute is a weird thing.  It mirrors TIF_IA32 and
> TIF_X32 and is used only in two very unrelated places: (1) to decide if
> the vsyscall page is accessible (2) for uprobes to find whether the
> patched instruction is 32 or 64 bit.  In preparation to remove the TI
> flags, we want new values for ia32_compat, but given its odd semantics,
> I'd rather make it a real flags field that configures these specific
> behaviours.  So, set_personality_x64 can ask for the vsyscall page,
> which is not available in x32/ia32 and set_personality_ia32 can
> configure the uprobe code as needed.
>
> uprobe cannot rely on other methods like user_64bit_mode() to decide how
> to patch, so it needs some specific flag like this.

Acked-by: Andy Lutomirski<luto@kernel.org>

There are still issues with vsyscall control, but they were
pre-existing and I'll try to get them fixed up.

--Andy