linux-kernel - Re: [GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 2

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: <72cb1319-e072-b3a1-8d1b-a86321b255b8@gmail.com>
Date:   Sat, 9 Sep 2023 00:32:37 +0900
From:   Akira Yokosawa <akiyks@...il.com>
To:     palmer@...osinc.com
Cc:     linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        torvalds@...ux-foundation.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Akira Yokosawa <akiyks@...il.com>
Subject: Re: [GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 2

On Sat, 9 Sep 2023 00:27:56 +0900, Akira Yokosawa wrote:
> On Fri, 08 Sep 2023 07:55:57 -0700 (PDT), Palmer Dabbelt wrote:
>> merged tag 'riscv-for-linus-6.6-mw1'
>> The following changes since commit e0152e7481c6c63764d6ea8ee41af5cf9dfac5e9:
>>
>>   Merge tag 'riscv-for-linus-6.6-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux (2023-09-01 08:09:48 -0700)
>>
>> are available in the Git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-6.6-mw2
>>
>> for you to fetch changes up to accb14aa1e699d11b8172283e8cb82a695b96c85:
>>
>>   soc: renesas: Kconfig: For ARCH_R9A07G043 select the required configs if dependencies are met (2023-09-06 07:20:13 -0700)
>>
>> ----------------------------------------------------------------
>> RISC-V Patches for the 6.6 Merge Window, Part 2
>>
>> * The kernel now dynamically probes for misaligned access speed, as
>>   opposed to relying on a table of known implementations.
>> * Support for non-coherent devices on systems using the Andes AX45MP
>>   core, including the RZ/Five SoCs.
>> * Support for the V extension in ptrace(), again.
>> * Support for KASLR.
>> * Support for the BPF prog pack allocator in RISC-V.
>> * A handful of bug fixes and cleanups.
>>
>> ----------------------------------------------------------------
>> The shortlog looks correct here, but the diffstat includes all sorts of files I
>> wasn't expecting.  I'm not entirely sure what's going on here, but I have a
>> little bit of a complex set of base branches here as the BPF changes have a
>> dependency on some arm64 BPF work and IIRC that sort of thing sometimes makes
>> diffstat go off the rails.  So hopefully that's just it.
> 
> Hi Palmer,
> It looks like you have ignored Stephen Rothwell's kind investigation at
> https://lore.kernel.org/linux-next/20230908082625.487d39c4@canb.auug.org.au/.

Aahh, Stephen used your email address at @dabbelt.com.
Didn't you see the message at all?

Akira

> 
> Excerpt of Stephen's analysis:
> 
>> Actually, it looks like the merge
>>
>>   2bf3c0292f35 ("Merge patch series "RISC-V: Probe for misaligned access speed"")
>>
>> in the risc-v tree was resolved very badly and dragged a lot of stuff
>> back in.
> 
> [...]
> 
>> When I redid that merge:
>>
>> $ git diff HEAD^..HEAD
>>  Documentation/riscv/hwprobe.rst      |  11 ++--
>>  arch/riscv/errata/thead/errata.c     |   8 ---
>>  arch/riscv/include/asm/alternative.h |   5 --
>>  arch/riscv/include/asm/cpufeature.h  |   2 +
>>  arch/riscv/kernel/Makefile           |   1 +
>>  arch/riscv/kernel/alternative.c      |  19 -------
>>  arch/riscv/kernel/copy-unaligned.S   |  71 ++++++++++++++++++++++++
>>  arch/riscv/kernel/copy-unaligned.h   |  13 +++++
>>  arch/riscv/kernel/cpufeature.c       | 104 +++++++++++++++++++++++++++++++++++
>>  arch/riscv/kernel/smpboot.c          |   3 +-
>>  10 files changed, 198 insertions(+), 39 deletions(-)
>>
>> So, the risc-v tree needs to be cleaned up.
> 
> Palmer, you are requesting pull without the suggested cleanup.
> 
> I'd really like this to be cleanly sorted out.
> 
> Of course, it's up to Linus whether or not to pull as it is...
> 
>         Thanks, Akira