[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Jun 2019 19:03:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jorgen Hansen <jhansen@...are.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"will.deacon@....com" <will.deacon@....com>,
"arnd@...db.de" <arnd@...db.de>, Vishnu DASA <vdasa@...are.com>,
Adit Ranadive <aditr@...are.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] VMCI: Fixup atomic64_t abuse
On Thu, Jun 06, 2019 at 03:54:24PM +0000, Jorgen Hansen wrote:
>
>
> > On 6 Jun 2019, at 11:34, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >
> > The VMCI driver is abusing atomic64_t and atomic_t, there is no actual
> > atomic RmW operations around.
> >
> > Rewrite the code to use a regular u64 with READ_ONCE() and
> > WRITE_ONCE() and a cast to 'unsigned long'. This fully preserves
> > whatever broken there was (it's not endian-safe for starters, and also
> > looks to be missing ordering).
>
> Thanks for the cleanup.
>
> This code is only intended for use with the vmci device driver, and
> that is X86 only, so during the original upstreaming no effort was
> made to make this work correctly on anything else.
Even x86 needs compiler barriers to ensure the compiler emits the
instructions in the expected order.
> We’ll be updating the vmci device driver to work on other
> architectures soonish, so will be adding barriers to enforce ordering
> as well at that point. If you want to leave your patch as is, we can
> address the type casting then.
You might want to have a look at smp_store_release() and
smp_load_acquire() I suppose.
Powered by blists - more mailing lists