linux-kernel - Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <mhng-0db73539-1462-456a-a6e2-63bb04c8e7e5@palmer-si-x1c4>
Date:   Mon, 10 Jul 2017 13:39:48 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     peterz@...radead.org
CC:     mingo@...hat.com, mcgrof@...nel.org, viro@...iv.linux.org.uk,
        sfr@...b.auug.org.au, nicolas.dichtel@...nd.com,
        rmk+kernel@...linux.org.uk, msalter@...hat.com,
        tklauser@...tanz.ch, will.deacon@....com, james.hogan@...tec.com,
        paul.gortmaker@...driver.com, linux@...ck-us.net,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        albert@...ive.com, patches@...ups.riscv.org
Subject:     Re: [PATCH 2/9] RISC-V: Atomic and Locking Code

On Fri, 07 Jul 2017 01:08:19 PDT (-0700), peterz@...radead.org wrote:
> On Thu, Jul 06, 2017 at 06:04:13PM -0700, Palmer Dabbelt wrote:
>>   +/*
>>   + * TODO_RISCV_MEMORY_MODEL: I don't think RISC-V is allowed to perform a
>>   + * speculative load, but we're going to wait on a formal memory model in order
>>   + * to ensure this is safe to elide.
>>   + */
>>   +#define smp_acquire__after_ctrl_dep()  smp_mb()
>
> So typically a control dependency already provides read->write ordering,
> by virtue of speculative writes being BAD.
>
> So a control dependency only needs to provide read->read ordering in
> addition to the existing read->write ordering and hence this barrier is
> typically a smp_rmb().
>
> See the definition in asm-generic/barrier.h.
>
> Having to use a full barrier here would imply your architecture does not
> respect control dependencies, which would be BAD because we actually
> rely on them.
>
> So either the normal definition is good and you don't need to do
> anything, or you prohibit read speculation in which case you have a
> special case like TILE does.

I'd be very surprised (and very unhappy) if we ended up with speculative
writes, as that would be a huge mess.

Thanks!