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  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 14 Aug 2020 13:34:05 +0100
From:   Mark Rutland <>
To:     Marco Elver <>
Cc:     Peter Zijlstra <>,
        "Paul E. McKenney" <>,
        Will Deacon <>, Arnd Bergmann <>,
        Dmitry Vyukov <>,
        Alexander Potapenko <>,
        kasan-dev <>,
        LKML <>,
        linux-arch <>
Subject: Re: [PATCH 8/8] locking/atomics: Use read-write instrumentation for
 atomic RMWs

On Fri, Aug 14, 2020 at 01:59:08PM +0200, Marco Elver wrote:
> On Fri, 14 Aug 2020 at 13:31, Mark Rutland <> wrote:
> > On Fri, Aug 14, 2020 at 12:28:26PM +0100, Mark Rutland wrote:
> > > Hi,
> > >
> > > Sorry to come to this rather late -- this comment equally applies to v2
> > > so I'm replying here to have context.
> >
> > ... and now I see that was already applied, so please ignore this!
> Thank you for the comment anyway. If this is something urgent, we
> could send a separate patch to change.

I'm not particularly concerned; it would've been nice for legibility but
I don't think it's very important. I'm happy with leaving it as-is or
with a cleanup at some point -- I'll defer to Peter to decide either

> My argument in favour of keeping it as-is was that the alternative
> would throw away the "type" and we no longer recognize a difference
> between arguments (in fairness, currently not important though). If,
> say, we get an RMW that has a constant argument though, the current
> version would do the "right thing" as far as I can tell. Maybe I'm
> overly conservative here, but it saves us worrying about some future
> use-case breaking this more than before.

I'd argue that clarity is preferable, since we'd have to change this to
deal with other variations in future (e.g. mixes of RW and W). I have
difficulty imagining an atomic op that'd work on multiple atomic
variables with different access types, so I suspect it's unlikely to

As above, not a big deal regardless.


Powered by blists - more mailing lists