[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a85dcc1f-4245-3c07-8d47-53b6c9ce12f9@suse.com>
Date: Mon, 20 Aug 2018 10:56:12 +0200
From: Juergen Gross <jgross@...e.com>
To: Jan Beulich <JBeulich@...e.com>
Cc: the arch/x86 maintainers <x86@...nel.org>, tglx@...utronix.de,
xen-devel <xen-devel@...ts.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, mingo@...hat.com,
linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [Xen-devel] [PATCH 2/2] x86/pae: use 64 bit atomic xchg function
in native_ptep_get_and_clear
On 20/08/18 10:40, Jan Beulich wrote:
>>>> On 20.08.18 at 07:14, <jgross@...e.com> wrote:
>> @@ -148,14 +150,14 @@ static inline void pud_clear(pud_t *pudp)
>> #ifdef CONFIG_SMP
>> static inline pte_t native_ptep_get_and_clear(pte_t *ptep)
>> {
>> - pte_t res;
>> + union {
>> + pte_t pte;
>> + long long val;
>> + } res;
>
> Why the union? pte_t already is one, with the pte field being what
> you're after ...
>
>> - /* xchg acts as a barrier before the setting of the high bits */
>> - res.pte_low = xchg(&ptep->pte_low, 0);
>> - res.pte_high = ptep->pte_high;
>> - ptep->pte_high = 0;
>> + res.val = arch_atomic64_xchg((atomic64_t *)ptep, 0);
>
> ... here.
Uuh, yes.
I'm waiting for more comments, especially regarding the potential need
for a paravirt function.
Juergen
Powered by blists - more mailing lists