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;
From:   Nadav Amit <namit@vmware.com>
To:     Jason Baron <jbaron@akamai.com>
CC:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Steven Rostedt <rostedt@goodmis.org>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Jiri Kosina <jkosina@suse.cz>,
        David Laight <David.Laight@ACULAB.COM>,
        Borislav Petkov <bp@alien8.de>,
        Julia Cartwright <julia@ni.com>, Jessica Yu <jeyu@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Edward Cree <ecree@solarflare.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH v3 5/6] x86/alternative: Use a single access in
 text_poke() where possible
Thread-Topic: [PATCH v3 5/6] x86/alternative: Use a single access in
 text_poke() where possible
Thread-Index: AQHUqG8Wf4/RNokb7ki08kHGReVe6KWoPeeAgACCrgCAAAOIgIAAAtyAgAAEMYCAAAHSAIABL4oAgAA3H4CAABXrAIAAAyYAgAAMFgCAAAPLAA==
Date:   Fri, 11 Jan 2019 17:54:43 +0000
Message-ID: <73A1EC50-AF51-4035-A3B3-D989AC89B929@vmware.com>
References: <279b8003f7f0a6831d090ab822d37bc958f974de.1547073843.git.jpoimboe@redhat.com>
 <8138A1EE-359D-4CD2-8E96-5BF00313AB3B@vmware.com>
 <20190110172004.wuh45xoafynfm2df@treble>
 <20190110123243.3b9e0856@gandalf.local.home>
 <20190110174257.GE16556@linux.intel.com>
 <20190110125757.1c8d2870@gandalf.local.home>
 <20190110180428.GG16556@linux.intel.com>
 <e5ea3781-336d-7b03-a22e-5012e915affd@oracle.com>
 <20190111152809.ejutcmqrx4ud3fli@treble>
 <ad6fae93-4122-7854-aa4c-2facd67ca839@oracle.com>
 <20190111165752.z6e2dfktj2caqi4n@treble>
 <d9b1c9b7-ae7b-80df-7b2f-19721f3460cf@akamai.com>
In-Reply-To: <d9b1c9b7-ae7b-80df-7b2f-19721f3460cf@akamai.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D367677AD9950C44AD5FD61480FFF74B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 094260b5-9e90-43f8-a520-08d677edde2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 17:54:43.6049
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4600
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> On Jan 11, 2019, at 9:41 AM, Jason Baron <jbaron@akamai.com> wrote:
>=20
> On 1/11/19 11:57 AM, Josh Poimboeuf wrote:
>> On Fri, Jan 11, 2019 at 05:46:36PM +0100, Alexandre Chartre wrote:
>>> On 01/11/2019 04:28 PM, Josh Poimboeuf wrote:
>>>> On Fri, Jan 11, 2019 at 01:10:52PM +0100, Alexandre Chartre wrote:
>>>>> To avoid any issue with live patching the call instruction, what abou=
t
>>>>> toggling between two call instructions: one would be the currently ac=
tive
>>>>> call, while the other would currently be inactive but to be used afte=
r a
>>>>> change is made. You can safely patch the inactive call and then toggl=
e
>>>>> the call flow (using a jump label) between the active and inactive ca=
lls.
>>>>>=20
>>>>> So instead of having a single call instruction:
>>>>>=20
>>>>> 	call function
>>>>>=20
>>>>> You would have:
>>>>>=20
>>>>> 	STATIC_JUMP_IF_TRUE label, key
>>>>> 	call function1
>>>>> 	jmp done
>>>>> label:
>>>>> 	call function2
>>>>> done:
>>>>>=20
>>>>> If the key is set so that function1 is currently called then you can
>>>>> safely update the call instruction for function2. Once this is done,
>>>>> just flip the key to make the function2 call active. On a next update=
,
>>>>> you would, of course, have to switch and update the call for function=
1.
>>>>=20
>>>> What about the following race?
>>>>=20
>>>> CPU1						CPU2
>>>> static key is false, doesn't jump
>>>> task gets preempted before calling function1
>>>> 						change static key to true
>>>> 						start patching "call function1"
>>>> task resumes, sees inconsistent call instruction
>>>=20
>>> If the function1 call is active then it won't be changed, you will chan=
ge
>>> function2. However, I presume you can still have a race but if the func=
tion
>>> is changed twice before calling function1:
>>>=20
>>> CPU1						CPU2
>>> static key is false, doesn't jump
>>> task gets preempted before calling function1
>>>                                                -- first function change=
 --
>>>                                                patch "call function2"
>>>                                                change static key to tru=
e
>>>                                                -- second function chang=
e --
>>>                                                start patching "call fun=
ction1"
>>> task resumes, sees inconsistent call instruction
>>>=20
>>> So right, that's a problem.
>>=20
>> Right, that's what I meant to say :-)
>=20
> could you use something like synchronize_rcu_tasks() between successive
> updates to guarantee nobody's stuck in the middle of the call
> instruction update? Yes its really slow but the update path is slow anywa=
ys.

You would need to disable preemption or IRQs before the call, which is not
something you want to do (when would you enable it?)

Having said that, I suggested something somewhat similar things here:
https://lore.kernel.org/lkml/F6735FF5-4D62-4C4E-A145-751E6469CE9E@vmware.co=
m/
https://lore.kernel.org/lkml/CCF7D3C7-9D12-489B-B778-C2156D2DBF47@vmware.co=
m/