[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Jun 2019 18:03:17 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jorgen Hansen <jhansen@...are.com>
Cc: Peter Zijlstra <peterz@...radead.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.
>
> With that in mind, it should be fine to drop the unsigned long * type
> casts, since the introduction of the 32 bit operations were only done
> to avoid an issue with cmpxchg8b on 32-bit, and just doing straight
> writes avoids that too.
>
> 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.
I've already applied it.
greg k-h
Powered by blists - more mailing lists