The following changes since commit 20e0fbab16003ae23a9e86a64bcb93e3121587ca:
perf: RISC-V: fix access beyond allocated array (2022-09-08 13:50:25 -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.0-rc6
for you to fetch changes up to 5b5f6556027ccb04c731988923c051fd2b2bad18:
RISC-V: Avoid coupling the T-Head CMOs and Zicbom (2022-09-16 02:59:06 -0700)
----------------------------------------------------------------
RISC-V Fixes for 6.0-rc6
* A handful of build fixes for the T-Head errata, including some
functional issues the compilers found.
* A fix to avoid bad page permission initialization, which manifests on
systems that may load modules early.
* A fix for a nasty sigreturn bug.
----------------------------------------------------------------
I have one merge conflict as a result of a treewide fix, I'm getting some odd
output from just showing the merge (it's showing some of the fix too), but I
think the merge itself is OK. My fix is to keep the write lock
- mmap_read_lock(mm);
++ mmap_write_lock(mm);
+ ret = walk_page_range_novma(mm, start, end, &pageattr_ops, NULL,
+ &masks);
- mmap_read_unlock(mm);
++ mmap_write_unlock(mm);
----------------------------------------------------------------
Al Viro (1):
riscv: fix a nasty sigreturn bug...
Heiko Stuebner (1):
riscv: make t-head erratas depend on MMU
Palmer Dabbelt (2):
RISC-V: Clean up the Zicbom block size probing
RISC-V: Avoid coupling the T-Head CMOs and Zicbom
Randy Dunlap (1):
riscv: fix RISCV_ISA_SVPBMT kconfig dependency warning
Vladimir Isaev (1):
riscv: Fix permissions for all mm's during mm init
arch/riscv/Kconfig | 1 +
arch/riscv/Kconfig.erratas | 4 +--
arch/riscv/errata/thead/errata.c | 1 +
arch/riscv/include/asm/cacheflush.h | 5 +++
arch/riscv/include/asm/set_memory.h | 20 +++---------
arch/riscv/kernel/setup.c | 13 +-------
arch/riscv/kernel/signal.c | 2 ++
arch/riscv/mm/dma-noncoherent.c | 23 ++++++++------
arch/riscv/mm/init.c | 29 ++++++++++++++---
arch/riscv/mm/pageattr.c | 62 ++++++++++++++++++++++++++++++++-----
10 files changed, 107 insertions(+), 53 deletions(-)
On Fri, Sep 16, 2022 at 8:31 AM Palmer Dabbelt <[email protected]> wrote:
>
> I have one merge conflict as a result of a treewide fix, I'm getting some odd
> output from just showing the merge (it's showing some of the fix too), but I
> think the merge itself is OK. My fix is to keep the write lock
>
> - mmap_read_lock(mm);
> ++ mmap_write_lock(mm);
> + ret = walk_page_range_novma(mm, start, end, &pageattr_ops, NULL,
> + &masks);
> - mmap_read_unlock(mm);
> ++ mmap_write_unlock(mm);
Yes, thatr's the proper merge resolution.
HOWEVER.
Looking at the *callers* of this new __set_memory_mm(), this is all
completely bogus and broken.
In particular, fix_kernel_mem_early() does that call under rcu_read_lock().
You can't do that. Not with the read-lock, and not with the
write-lock. You simply cannot (and must not) block while in a
read-side critical section, and trying to take any sleeping lock -
whether for reading or for writing - is just completely wrong.
So I'm not doing this pull. The merge resolution is trivial, but the
code is simply wrong.
Linus
On Fri, 16 Sep 2022 13:09:21 PDT (-0700), Linus Torvalds wrote:
> On Fri, Sep 16, 2022 at 8:31 AM Palmer Dabbelt <[email protected]> wrote:
>>
>> I have one merge conflict as a result of a treewide fix, I'm getting some odd
>> output from just showing the merge (it's showing some of the fix too), but I
>> think the merge itself is OK. My fix is to keep the write lock
>>
>> - mmap_read_lock(mm);
>> ++ mmap_write_lock(mm);
>> + ret = walk_page_range_novma(mm, start, end, &pageattr_ops, NULL,
>> + &masks);
>> - mmap_read_unlock(mm);
>> ++ mmap_write_unlock(mm);
>
> Yes, thatr's the proper merge resolution.
>
> HOWEVER.
>
> Looking at the *callers* of this new __set_memory_mm(), this is all
> completely bogus and broken.
>
> In particular, fix_kernel_mem_early() does that call under rcu_read_lock().
>
> You can't do that. Not with the read-lock, and not with the
> write-lock. You simply cannot (and must not) block while in a
> read-side critical section, and trying to take any sleeping lock -
> whether for reading or for writing - is just completely wrong.
>
> So I'm not doing this pull. The merge resolution is trivial, but the
> code is simply wrong.
Sorry about that, it's pretty brain-dead. I'd love to blame this one on
the lack of sleep over the past week or two, but I'm a bit too tired to
commit to that. Either way I'll go sort it out, but not for this week
-- I don't think anything else was super critical, so it shouldn't be
that big of a problem.