linux-kernel - Re: [PATCH 8/8] locking/atomics: Use read-write instrumentation for atomic RMWs

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 linux-hardening linux-cve-announce 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]

Message-ID: <20200814123405.GD68877@C02TD0UTHF1T.local>
Date:   Fri, 14 Aug 2020 13:34:05 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Marco Elver <elver@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
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 <mark.rutland@....com> 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
way.

> 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
happen.

As above, not a big deal regardless.

Thanks,
Mark.