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 <>
To:     Jorgen Hansen <>
Cc:     Peter Zijlstra <>,
        Andrea Parri <>,
        "" <>,
        "" <>,
        "" <>, Vishnu DASA <>,
        Adit Ranadive <>,
        Steven Rostedt <>
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 <> 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