linux-kernel - Re: [PATCH -next v2 1/2] riscv: uaccess: rename __get/put_user_nocheck to __get/put_mem

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: <CAK8P3a0akgBkyVQuAfi5qdi9O5DhxZJ3FknxGH-gedpJpAVw6w@mail.gmail.com>
Date:   Sat, 27 Aug 2022 14:49:13 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Tong Tiangen <tongtiangen@...wei.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Palmer Dabbelt <palmer@...osinc.com>,
        Albert Ou <aou@...s.berkeley.edu>, Conor.Dooley@...rochip.com,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        wangkefeng.wang@...wei.com, Guohanjun <guohanjun@...wei.com>
Subject: Re: [PATCH -next v2 1/2] riscv: uaccess: rename __get/put_user_nocheck
 to __get/put_mem_nocheck

On Sat, Aug 27, 2022 at 12:43 PM Tong Tiangen <tongtiangen@...wei.com> wrote:
> 在 2022/8/26 17:30, Arnd Bergmann 写道:
>
> I am very interested in the implementation of X86. I need to investigate
> and consider a cross architecture implementation.

One more point about the cross-architecture work: it generally makes
sense to do the most commonly used architectures first, usually
that would be x86, arm64 and powerpc64, followed by riscv, arm,
s390 and mips. If we can find something that the first architecture
maintainers like, everyone else can follow and you don't have to
rework all of them multiple times before getting to a consensus.

> However, I understand that the modification of the current patch has
> little to do with the two points mentioned above. We can optimize the
> code step by step.

You are correct that this has little to do with your patch, my point
was mainly that your patch is moving the code further away from
the other architectures, so it would make it harder to then do the
changes we actually want.

       Arnd