linux-kernel - Re: [patches] [RFC] RISC-V: Don't set CLONE

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: <20180109081145.GA2094@lst.de>
Date:   Tue, 9 Jan 2018 09:11:45 +0100
From:   Christoph Hellwig <hch@....de>
To:     patches@...ups.riscv.org
Cc:     linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>,
        Palmer Dabbelt <palmer@...ive.com>,
        Adhemerval Zanella <adhemerval.zanella@...aro.org>
Subject: Re: [patches] [RFC] RISC-V: Don't set CLONE_BACKWARDS

On Mon, Jan 08, 2018 at 05:27:56PM -0800, Palmer Dabbelt wrote:
> During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
> deprecated ABI decision.  I think we just copied it from ARM, but I
> don't see any reason to favor one over the other.
> 
> While we haven't released yet so I think it's still legal to change our
> ABI, I'd actually kind of prefer to avoid changing our ABI this late in
> the game.  I guess this is more of an RFC than a patch: is there a
> reason to avoid CLONE_BACKWARDS?
> 
> Note that I haven't tried any of this -- I'll give it some thourough
> testing and submit an actual patch if this is the way we want to go.

I see absolutely no reason to change this.  Linux currently has 30
architecture port, out of which 10 (including riscv, i386, arm and arm64)
set CLONE_BACKWARDS.

There are no performance benefits of doing it one way or another, and
changing it now will break all the riscv enablement that's been going
on.