From: Peter Zijlstra <peterz@infradead.org>
To: Jorgen Hansen <jhansen@vmware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"arnd@arndb.de" <arnd@arndb.de>, Vishnu DASA <vdasa@vmware.com>,
Adit Ranadive <aditr@vmware.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] VMCI: Fixup atomic64_t abuse
Date: Thu, 6 Jun 2019 19:03:50 +0200 [thread overview]
Message-ID: <20190606170350.GL3419@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <BC2D213B-89E4-4C14-A093-AC61EAB56830@vmware.com>
On Thu, Jun 06, 2019 at 03:54:24PM +0000, Jorgen Hansen wrote:
>
>
> > On 6 Jun 2019, at 11:34, Peter Zijlstra <peterz@infradead.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.
next prev parent reply other threads:[~2019-06-06 17:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 9:34 [PATCH] VMCI: Fixup atomic64_t abuse Peter Zijlstra
2019-06-06 15:54 ` Jorgen Hansen
2019-06-06 16:03 ` Greg Kroah-Hartman
2019-06-06 17:03 ` Peter Zijlstra [this message]
2019-06-06 16:02 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190606170350.GL3419@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aditr@vmware.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jhansen@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=vdasa@vmware.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.