From: Jisheng Zhang <jszhang@kernel.org>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: fix load_unaligned_zeropad() fixup for RV32
Date: Tue, 8 Sep 2026 11:36:08 +0800 [thread overview]
Message-ID: <ap-CqOtyN9qvWHOb@xhacker> (raw)
In-Reply-To: <20260907190750.26303-1-kmehltretter@gmail.com>
On Mon, Sep 07, 2026 at 09:07:50PM +0200, Karl Mehltretter wrote:
> The fixup for load_unaligned_zeropad() runs when REG_L crosses into an
> unmapped page. REG_L is lw on RV32 and ld on RV64, but the fixup assumes
> an 8-byte load: it rounds the address down to 8 bytes and derives the
> shift from three address bits.
>
> On RV32, a load starting in the last three bytes of a mapped page selects
> the word four bytes earlier and shifts it by 40, 48, or 56 bits, more than
> the register width. The caller gets earlier bytes instead of the string
> tail followed by zeroes. This affects RV32 MMU kernels built with
> RISCV_EFFICIENT_UNALIGNED_ACCESS=y, which selects DCACHE_WORD_ACCESS
> and lets dcache name hashing and comparison and strscpy() use this
> path.
>
> Derive the alignment and offset masks from sizeof(data) instead of a fixed
> 8. This makes RV32 use the correct source word. RV64 code is unchanged: the
> complete extable.o is byte-for-byte identical before and after.
>
> Fixes: d0fdc20b0429 ("riscv: select DCACHE_WORD_ACCESS for efficient unaligned access HW")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
> ---
> Tested on RV32 QEMU virt/TCG with a KUnit guard-page test. Before, the last
> three offsets returned fill bytes from the previous word (0xa5, 0xa5a5, and
> 0xa5a5a5) instead of the string tail (0x44, 0x4433, and 0x443322), and the
> suite failed. After, all three cases and the suite passed.
>
> Built full RV32 Images for both sides with GCC 15.2.0. The complete RV64
> extable.o is byte-for-byte identical before and after the change.
>
> arch/riscv/mm/extable.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/mm/extable.c b/arch/riscv/mm/extable.c
> index dd1530af3ef1..e252eba55ede 100644
> --- a/arch/riscv/mm/extable.c
> +++ b/arch/riscv/mm/extable.c
> @@ -68,8 +68,8 @@ ex_handler_load_unaligned_zeropad(const struct exception_table_entry *ex,
>
> addr = regs_get_gpr(regs, reg_addr * sizeof(unsigned long));
>
> - offset = addr & 0x7UL;
> - addr &= ~0x7UL;
> + offset = addr & (sizeof(data) - 1);
> + addr &= ~(sizeof(data) - 1);
>
> data = *(unsigned long *)addr >> (offset * 8);
>
> --
> 2.53.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <jszhang@kernel.org>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: fix load_unaligned_zeropad() fixup for RV32
Date: Tue, 8 Sep 2026 11:36:08 +0800 [thread overview]
Message-ID: <ap-CqOtyN9qvWHOb@xhacker> (raw)
In-Reply-To: <20260907190750.26303-1-kmehltretter@gmail.com>
On Mon, Sep 07, 2026 at 09:07:50PM +0200, Karl Mehltretter wrote:
> The fixup for load_unaligned_zeropad() runs when REG_L crosses into an
> unmapped page. REG_L is lw on RV32 and ld on RV64, but the fixup assumes
> an 8-byte load: it rounds the address down to 8 bytes and derives the
> shift from three address bits.
>
> On RV32, a load starting in the last three bytes of a mapped page selects
> the word four bytes earlier and shifts it by 40, 48, or 56 bits, more than
> the register width. The caller gets earlier bytes instead of the string
> tail followed by zeroes. This affects RV32 MMU kernels built with
> RISCV_EFFICIENT_UNALIGNED_ACCESS=y, which selects DCACHE_WORD_ACCESS
> and lets dcache name hashing and comparison and strscpy() use this
> path.
>
> Derive the alignment and offset masks from sizeof(data) instead of a fixed
> 8. This makes RV32 use the correct source word. RV64 code is unchanged: the
> complete extable.o is byte-for-byte identical before and after.
>
> Fixes: d0fdc20b0429 ("riscv: select DCACHE_WORD_ACCESS for efficient unaligned access HW")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
> ---
> Tested on RV32 QEMU virt/TCG with a KUnit guard-page test. Before, the last
> three offsets returned fill bytes from the previous word (0xa5, 0xa5a5, and
> 0xa5a5a5) instead of the string tail (0x44, 0x4433, and 0x443322), and the
> suite failed. After, all three cases and the suite passed.
>
> Built full RV32 Images for both sides with GCC 15.2.0. The complete RV64
> extable.o is byte-for-byte identical before and after the change.
>
> arch/riscv/mm/extable.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/mm/extable.c b/arch/riscv/mm/extable.c
> index dd1530af3ef1..e252eba55ede 100644
> --- a/arch/riscv/mm/extable.c
> +++ b/arch/riscv/mm/extable.c
> @@ -68,8 +68,8 @@ ex_handler_load_unaligned_zeropad(const struct exception_table_entry *ex,
>
> addr = regs_get_gpr(regs, reg_addr * sizeof(unsigned long));
>
> - offset = addr & 0x7UL;
> - addr &= ~0x7UL;
> + offset = addr & (sizeof(data) - 1);
> + addr &= ~(sizeof(data) - 1);
>
> data = *(unsigned long *)addr >> (offset * 8);
>
> --
> 2.53.0
next prev parent reply other threads:[~2026-09-08 3:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 19:07 [PATCH] riscv: fix load_unaligned_zeropad() fixup for RV32 Karl Mehltretter
2026-09-07 19:07 ` Karl Mehltretter
2026-09-08 3:36 ` Jisheng Zhang [this message]
2026-09-08 3:36 ` Jisheng Zhang
2026-10-07 6:27 ` Karl Mehltretter
2026-10-07 6:27 ` Karl Mehltretter
2026-10-08 2:40 ` patchwork-bot+linux-riscv
2026-10-08 2:40 ` patchwork-bot+linux-riscv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ap-CqOtyN9qvWHOb@xhacker \
--to=jszhang@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=kmehltretter@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.