Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <925F22EA-F8CB-4194-B96B-378409ED7918@vmware.com>
Date:   Thu, 18 Oct 2018 10:00:37 -0700
Cc:     Ingo Molnar <mingo@redhat.com>,
        Andrew Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        "Woodhouse, David" <dwmw@amazon.co.uk>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2626124E-7344-42F3-AD07-0BB34D62A9EE@amacapital.net>
References: <20181018005420.82993-1-namit@vmware.com> <20181018005420.82993-2-namit@vmware.com> <D247AB7C-2890-49CE-B102-163E5B368FC2@amacapital.net> <07255D2B-0243-4254-B62A-37050C44207E@vmware.com> <CALCETrXEG8OrMpB3VBS9RF41O_MwtPmXBazkdSGE0ohZmXDcBw@mail.gmail.com> <925F22EA-F8CB-4194-B96B-378409ED7918@vmware.com>
To:     Nadav Amit <namit@vmware.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Oct 18, 2018, at 9:47 AM, Nadav Amit <namit@vmware.com> wrote:
>=20
> at 8:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>=20
>>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit <namit@vmware.com> wrote:
>>> at 6:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>=20
>>>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit <namit@vmware.com> wrote:
>>>>>=20
>>>>> It is sometimes beneficial to prevent preemption for very few
>>>>> instructions, or prevent preemption for some instructions that precede=

>>>>> a branch (this latter case will be introduced in the next patches).
>>>>>=20
>>>>> To provide such functionality on x86-64, we use an empty REX-prefix
>>>>> (opcode 0x40) as an indication that preemption is disabled for the
>>>>> following instruction.
>>>>=20
>>>> Nifty!
>>>>=20
>>>> That being said, I think you have a few bugs. First, you can=E2=80=99t j=
ust ignore
>>>> a rescheduling interrupt, as you introduce unbounded latency when this
>>>> happens =E2=80=94 you=E2=80=99re effectively emulating preempt_enable_n=
o_resched(), which
>>>> is not a drop-in replacement for preempt_enable(). To fix this, you may=

>>>> need to jump to a slow-path trampoline that calls schedule() at the end=
 or
>>>> consider rewinding one instruction instead. Or use TF, which is only a
>>>> little bit terrifying=E2=80=A6
>>>=20
>>> Yes, I didn=E2=80=99t pay enough attention here. For my use-case, I thin=
k that the
>>> easiest solution would be to make synchronize_sched() ignore preemptions=

>>> that happen while the prefix is detected. It would slightly change the
>>> meaning of the prefix.
>=20
> So thinking about it further, rewinding the instruction seems the easiest
> and most robust solution. I=E2=80=99ll do it.
>=20
>>>> You also aren=E2=80=99t accounting for the case where you get an except=
ion that
>>>> is, in turn, preempted.
>>>=20
>>> Hmm.. Can you give me an example for such an exception in my use-case? I=

>>> cannot think of an exception that might be preempted (assuming #BP, #MC
>>> cannot be preempted).
>>=20
>> Look for cond_local_irq_enable().
>=20
> I looked at it. Yet, I still don=E2=80=99t see how exceptions might happen=
 in my
> use-case, but having said that - this can be fixed too.

I=E2=80=99m not totally certain there=E2=80=99s a case that matters.  But it=
=E2=80=99s worth checking=20

>=20
> To be frank, I paid relatively little attention to this subject. Any
> feedback about the other parts and especially on the high-level approach? I=
s
> modifying the retpolines in the proposed manner (assembly macros)
> acceptable?
>=20

It=E2=80=99s certainly a neat idea, and it could be a real speedup.

> Thanks,
> Nadav