[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<176355541326.758643.4317027962321955415.git-patchwork-notify@kernel.org>
Date: Wed, 19 Nov 2025 12:30:13 +0000
From: patchwork-bot+linux-riscv@...nel.org
To: Yong-Xuan Wang <yongxuan.wang@...ive.com>
Cc: linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, greentime.hu@...ive.com,
vincent.chen@...ive.com, andybnac@...il.com, pjw@...nel.org,
palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr
Subject: Re: [PATCH v2 0/2] Optimize the allocation of vector regset
Hello:
This series was applied to riscv/linux.git (for-next)
by Paul Walmsley <pjw@...nel.org>:
On Mon, 13 Oct 2025 17:12:30 +0800 you wrote:
> The vector regset uses the maximum possible vlenb 8192 to allocate a
> 2^18 bytes buffer to copy the vector register. But most platforms
> don’t support the largest vlenb.
>
> The regset has 2 users, ptrace syscall and coredump. When handling the
> PTRACE_GETREGSET requests from ptrace syscall, Linux will prepare a
> kernel buffer which size is min(user buffer size, limit). A malicious
> user process might overwhelm a memory-constrainted system when the
> buffer limit is very large. The coredump uses regset_get_alloc() to
> get the context of vector register. But this API allocates buffer
> before checking whether the target process uses vector extension, this
> wastes time to prepare a large memory buffer.
>
> [...]
Here is the summary with links:
- [v2,1/2] riscv: ptrace: Optimize the allocation of vector regset
https://git.kernel.org/riscv/c/f8e257e4d549
- [v2,2/2] selftests: riscv: Add test for the Vector ptrace interface
https://git.kernel.org/riscv/c/92678c40038b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists