lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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