[v2] RISC-V: Add ptrace support for vectors

Commit Message

Andy Chiu Aug. 25, 2023, 5:02 a.m. UTC

This patch add back the ptrace support with the following fix:
 - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
   conflicting with gdb's NT_RISCV_CSR.
 - Use struct __riscv_v_regset_state to handle ptrace requests

Since gdb does not directly include the note description header in
Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
conflicts.

Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
Signed-off-by: Andy Chiu <[e-mail]>
---
Changelog V2:
 - Remove [1/3], [2/3] from v1 as they have been merged
 - Define a new struct __riscv_v_regset_state for ptrace API to prevent
   dealing with extra datap space in userspace (Maciej).

 arch/riscv/include/uapi/asm/ptrace.h | 13 +++--
 arch/riscv/kernel/ptrace.c           | 79 ++++++++++++++++++++++++++++
 include/uapi/linux/elf.h             |  2 +
 3 files changed, 90 insertions(+), 4 deletions(-)

Comments

[e-mail] Aug. 30, 2023, 8:30 p.m. UTC | #1

Hello:

This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <[e-mail]>:

On Fri, 25 Aug 2023 05:02:46 +0000 you wrote:
> This patch add back the ptrace support with the following fix:
>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>    conflicting with gdb's NT_RISCV_CSR.
>  - Use struct __riscv_v_regset_state to handle ptrace requests
> 
> Since gdb does not directly include the note description header in
> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
> conflicts.
> 
> [...]

Here is the summary with links:
  - [v2] RISC-V: Add ptrace support for vectors
    https://git.kernel.org/riscv/c/dbe46b094026

You are awesome, thank you!

Nick Desaulniers Aug. 31, 2023, 5:05 p.m. UTC | #2

On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
> This patch add back the ptrace support with the following fix:
>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>    conflicting with gdb's NT_RISCV_CSR.
>  - Use struct __riscv_v_regset_state to handle ptrace requests
> 
> Since gdb does not directly include the note description header in
> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
> conflicts.
> 
> Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
> Signed-off-by: Andy Chiu <[e-mail]>

Hi Andy, this is causing an instance of -Wunused-variable. PTAL.

Please use the following tags on the fix:

Reported-by: "kernelci.org bot" <[e-mail]>
Closes: https://lore.kernel.org/linux-next/[e-mail]/

Let's see if I can get the regzbot tag correct; first time trying it.

#regzbot introduced dbe46b094026

> diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
> index 487303e3ef22..9a87e5d490b5 100644
> --- a/arch/riscv/kernel/ptrace.c
> +++ b/arch/riscv/kernel/ptrace.c
> @@ -81,6 +84,71 @@ static int riscv_fpr_set(struct task_struct *target,
>  }
>  #endif
>  
> +#ifdef CONFIG_RISCV_ISA_V
> +static int riscv_vr_get(struct task_struct *target,
> +			const struct user_regset *regset,
> +			struct membuf to)
> +{
> +	struct __riscv_v_ext_state *vstate = &target->thread.vstate;
> +	struct __riscv_v_regset_state ptrace_vstate;
> +
> +	if (!riscv_v_vstate_query(task_pt_regs(target)))
> +		return -EINVAL;
> +
> +	/*
> +	 * Ensure the vector registers have been saved to the memory before
> +	 * copying them to membuf.
> +	 */
> +	if (target == current)
> +		riscv_v_vstate_save(current, task_pt_regs(current));
> +
> +	ptrace_vstate.vstart = vstate->vstart;
> +	ptrace_vstate.vl = vstate->vl;
> +	ptrace_vstate.vtype = vstate->vtype;
> +	ptrace_vstate.vcsr = vstate->vcsr;
> +	ptrace_vstate.vlenb = vstate->vlenb;
> +
> +	/* Copy vector header from vstate. */
> +	membuf_write(&to, &ptrace_vstate, sizeof(struct __riscv_v_regset_state));
> +
> +	/* Copy all the vector registers from vstate. */
> +	return membuf_write(&to, vstate->datap, riscv_v_vsize);
> +}
> +
> +static int riscv_vr_set(struct task_struct *target,
> +			const struct user_regset *regset,
> +			unsigned int pos, unsigned int count,
> +			const void *kbuf, const void __user *ubuf)
> +{
> +	int ret, size;

^ arch/riscv/kernel/ptrace.c:123:11: warning: unused variable 'size' [-Wunused-variable]

Conor Dooley Aug. 31, 2023, 5:17 p.m. UTC | #3

On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
> > This patch add back the ptrace support with the following fix:
> >  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
> >    conflicting with gdb's NT_RISCV_CSR.
> >  - Use struct __riscv_v_regset_state to handle ptrace requests
> > 
> > Since gdb does not directly include the note description header in
> > Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
> > sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
> > conflicts.
> > 
> > Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
> > Signed-off-by: Andy Chiu <[e-mail]>
> 
> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
> 
> Please use the following tags on the fix:
> 
> Reported-by: "kernelci.org bot" <[e-mail]>
> Closes: https://lore.kernel.org/linux-next/[e-mail]/
> 
> Let's see if I can get the regzbot tag correct; first time trying it.
> 
> #regzbot introduced dbe46b094026

See <[e-mail]> for the fix.

That has you gave regzbot prob won't be stable though, branch needs a
rebase to add missing SoB tags from its committer.

Linux regression tracking (Thorsten Leemhuis) Aug. 31, 2023, 5:50 p.m. UTC | #4

On 31.08.23 19:17, Conor Dooley wrote:
> On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
>> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
>>> This patch add back the ptrace support with the following fix:
>>>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>>>    conflicting with gdb's NT_RISCV_CSR.
>>>  - Use struct __riscv_v_regset_state to handle ptrace requests
>>>
>>> Since gdb does not directly include the note description header in
>>> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
>>> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
>>> conflicts.
>>>
>>> Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
>>> Signed-off-by: Andy Chiu <[e-mail]>
>>
>> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
>>
>> Please use the following tags on the fix:
>>
>> Reported-by: "kernelci.org bot" <[e-mail]>
>> Closes: https://lore.kernel.org/linux-next/[e-mail]/
>>
>> Let's see if I can get the regzbot tag correct; first time trying it.
>> #regzbot introduced dbe46b094026

Nick, thx for trying, but FWIW, that's was slightly off, but there might
be a easy workaround. To explain for anyone that cares:

Due to that '#regzbot introduced ...' regzbot will consider the mail
with the "#regzbot introduced dbe46b094026" (e.g. the msg from Nick with
the msgid [e-mail]) as a report for this regression
and thus look out for patches and commits with a tag like this:

 Closes: https://lore.kernel.org/all/[e-mail]/

Which is kinda correct, as your mail *is* a report about the regression,
so some developer might use this. But in this case that's not what Nick
wanted, as there was an earlier report that was even specified. But
well, that might make it easy to fix, as we could simply tell regzbot
about the duplicate. Nick could have done that in his mail, but I can do
it in this one was well (as it's a indirect reply to the report from
Nick that regzbot track) that [e-mail]
is a duplicate of [e-mail]:

#regzbot dup-of:
https://lore.kernel.org/linux-next/[e-mail]/

Let's see if this works. I haven't used this much, so maybe something
might go sideways; but in theory this should work and then regzbot would
do the right thing. At least normally:

> See <[e-mail]> for the fix.
> 
> That has you gave regzbot prob won't be stable though, branch needs a
> rebase to add missing SoB tags from its committer.

You mean the commit-id of the change currently known as dbe46b094026
will change? Ughh, yeah, that's unfortunate and something regzbot is not
yet prepared for.

Hmmmm. Haven't had this case yet, as regzbot until now is not used much
for -next. Not sure how to best handle that. Sure, regzbot could notice
"the commit formerly known as cafec0c0 is now now c0c0cafe, as the
subject, author, and modified files roughly match" -- but I'm not sure
if that's a good idea, as developers like Conor might integrate simple
fixes like the one for the problem at hand during the rebase. So maybe
at this point it becomes "some human needs to look into this and tell
regzbot what to do". :-/

Ciao, Thorsten

Nick Desaulniers Aug. 31, 2023, 5:59 p.m. UTC | #5

On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis
<[e-mail]> wrote:
>
> On 31.08.23 19:17, Conor Dooley wrote:
> > On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
> >> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
> >>> This patch add back the ptrace support with the following fix:
> >>>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
> >>>    conflicting with gdb's NT_RISCV_CSR.
> >>>  - Use struct __riscv_v_regset_state to handle ptrace requests
> >>>
> >>> Since gdb does not directly include the note description header in
> >>> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
> >>> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
> >>> conflicts.
> >>>
> >>> Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
> >>> Signed-off-by: Andy Chiu <[e-mail]>
> >>
> >> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
> >>
> >> Please use the following tags on the fix:
> >>
> >> Reported-by: "kernelci.org bot" <[e-mail]>
> >> Closes: https://lore.kernel.org/linux-next/[e-mail]/
> >>
> >> Let's see if I can get the regzbot tag correct; first time trying it.
> >> #regzbot introduced dbe46b094026
>
> Nick, thx for trying, but FWIW, that's was slightly off, but there might
> be a easy workaround. To explain for anyone that cares:
>
> Due to that '#regzbot introduced ...' regzbot will consider the mail
> with the "#regzbot introduced dbe46b094026" (e.g. the msg from Nick with
> the msgid [e-mail]) as a report for this regression
> and thus look out for patches and commits with a tag like this:
>
>  Closes: https://lore.kernel.org/all/[e-mail]/
>
> Which is kinda correct, as your mail *is* a report about the regression,
> so some developer might use this. But in this case that's not what Nick
> wanted, as there was an earlier report that was even specified. But
> well, that might make it easy to fix, as we could simply tell regzbot
> about the duplicate.

Ah sorry about that. I tried.

I'm still unclear on what I should have done though.

Should I have replied to
https://lore.kernel.org/linux-next/[e-mail]/
with that same regzbot tag that I used instead?

> Nick could have done that in his mail, but I can do
> it in this one was well (as it's a indirect reply to the report from
> Nick that regzbot track) that [e-mail]
> is a duplicate of [e-mail]:
>
> #regzbot dup-of:
> https://lore.kernel.org/linux-next/[e-mail]/

Thanks for cleaning that up; sorry for the mess.

>
> Let's see if this works. I haven't used this much, so maybe something
> might go sideways; but in theory this should work and then regzbot would
> do the right thing. At least normally:
>
> > See <[e-mail]> for the fix.
> >
> > That has you gave regzbot prob won't be stable though, branch needs a
> > rebase to add missing SoB tags from its committer.
>
> You mean the commit-id of the change currently known as dbe46b094026
> will change? Ughh, yeah, that's unfortunate and something regzbot is not
> yet prepared for.
>
> Hmmmm. Haven't had this case yet, as regzbot until now is not used much
> for -next. Not sure how to best handle that. Sure, regzbot could notice
> "the commit formerly known as cafec0c0 is now now c0c0cafe, as the
> subject, author, and modified files roughly match" -- but I'm not sure
> if that's a good idea, as developers like Conor might integrate simple
> fixes like the one for the problem at hand during the rebase. So maybe
> at this point it becomes "some human needs to look into this and tell
> regzbot what to do". :-/

How about if someone drops a patch after it's been reported to
regzbot?  Is there currently any way to instruct regzbot to "forget
about the previous report?"

Perhaps that's only a common workflow in -next.

Linux regression tracking (Thorsten Leemhuis) Aug. 31, 2023, 6:24 p.m. UTC | #6

On 31.08.23 19:59, Nick Desaulniers wrote:
> On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis
> <[e-mail]> wrote:
>>
>> On 31.08.23 19:17, Conor Dooley wrote:
>>> On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
>>>> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
>>>>> This patch add back the ptrace support with the following fix:
>>>>>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>>>>>    conflicting with gdb's NT_RISCV_CSR.
>>>>>  - Use struct __riscv_v_regset_state to handle ptrace requests
>>>>>
>>>>> Since gdb does not directly include the note description header in
>>>>> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
>>>>> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
>>>>> conflicts.
>>>>>
>>>>> Fixes: 0c59922c769a ("riscv: Add ptrace vector support")
>>>>> Signed-off-by: Andy Chiu <[e-mail]>
>>>>
>>>> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
>>>>
>>>> Please use the following tags on the fix:
>>>>
>>>> Reported-by: "kernelci.org bot" <[e-mail]>
>>>> Closes: https://lore.kernel.org/linux-next/[e-mail]/
>>>>
>>>> Let's see if I can get the regzbot tag correct; first time trying it.
>>>> #regzbot introduced dbe46b094026
>>
>> Nick, thx for trying, but FWIW, that's was slightly off, but there might
>> be a easy workaround. To explain for anyone that cares:
>>
>> Due to that '#regzbot introduced ...' regzbot will consider the mail
>> with the "#regzbot introduced dbe46b094026" (e.g. the msg from Nick with
>> the msgid [e-mail]) as a report for this regression
>> and thus look out for patches and commits with a tag like this:
>>
>>  Closes: https://lore.kernel.org/all/[e-mail]/
>>
>> Which is kinda correct, as your mail *is* a report about the regression,
>> so some developer might use this. But in this case that's not what Nick
>> wanted, as there was an earlier report that was even specified. But
>> well, that might make it easy to fix, as we could simply tell regzbot
>> about the duplicate.
> 
> Ah sorry about that. I tried.

Again: thx for trying, I'm sure we'll get there.

> I'm still unclear on what I should have done though.
>> Should I have replied to
> https://lore.kernel.org/linux-next/[e-mail]/
> with that same regzbot tag that I used instead?

Nearly, just that you need to use "regzbot ^introduced <commit_id>" in
that case (with the caret) to instruct regzbot to consider the parent
mail as the report (the one you would have replied to).

/me wonders how all this could be made earlier and if the regzbot docs
are not explaining this well enough; but well, doing this by mail brings
some complexity that is hard to avoid :-/

https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md

>> Nick could have done that in his mail, but I can do
>> it in this one was well (as it's a indirect reply to the report from
>> Nick that regzbot track) that [e-mail]
>> is a duplicate of [e-mail]:
>>
>> #regzbot dup-of:
>> https://lore.kernel.org/linux-next/[e-mail]/
> 
> Thanks for cleaning that up; sorry for the mess.

No problem.

>> Let's see if this works. I haven't used this much, so maybe something
>> might go sideways; but in theory this should work and then regzbot would
>> do the right thing. At least normally:
>>
>>> See <[e-mail]> for the fix.
>>>
>>> That has you gave regzbot prob won't be stable though, branch needs a
>>> rebase to add missing SoB tags from its committer.
>>
>> You mean the commit-id of the change currently known as dbe46b094026
>> will change? Ughh, yeah, that's unfortunate and something regzbot is not
>> yet prepared for.
>>
>> Hmmmm. Haven't had this case yet, as regzbot until now is not used much
>> for -next. Not sure how to best handle that. Sure, regzbot could notice
>> "the commit formerly known as cafec0c0 is now now c0c0cafe, as the
>> subject, author, and modified files roughly match" -- but I'm not sure
>> if that's a good idea, as developers like Conor might integrate simple
>> fixes like the one for the problem at hand during the rebase. So maybe
>> at this point it becomes "some human needs to look into this and tell
>> regzbot what to do". :-/
> 
> How about if someone drops a patch after it's been reported to
> regzbot?  Is there currently any way to instruct regzbot to "forget
> about the previous report?"

Simply send a reply to what regzbot considers the report (or a mail that
itself is directly or indirectly a reply -- e.g. a mail like this) and
use mark the regression as resolved using something like this

 #regzbot resolve: culprit rebased and fix folded in

Or if the culprit would have gotten a stable commit-id and the fix was
separate something like this would work

 #regzbot introduced: <new_commit_hexsha>
 #regzbot fix: RISC-V: Remove unused "size" in ptrace

(for 'regzbot fix' one can use a commit-id, too (if it's stable))

In this case regzbot will ignore all of the above due to the spaces
before the ' #regzbot'.

> Perhaps that's only a common workflow in -next.

Yeah, for this case it for nor likely is good enough.

Ciao, Thorsten

Palmer Dabbelt Aug. 31, 2023, 9:58 p.m. UTC | #7

On Fri, 25 Aug 2023 05:02:46 +0000, Andy Chiu wrote:
> This patch add back the ptrace support with the following fix:
>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>    conflicting with gdb's NT_RISCV_CSR.
>  - Use struct __riscv_v_regset_state to handle ptrace requests
> 
> Since gdb does not directly include the note description header in
> Linux and has already defined NT_RISCV_CSR as 0x900, we decide to
> sync with gdb and renumber NT_RISCV_VECTOR to solve and prevent future
> conflicts.
> 
> [...]

Applied, thanks!

[1/1] RISC-V: Add ptrace support for vectors
      https://git.kernel.org/palmer/c/1e4e7c306d52

Best regards,

Linux regression tracking (Thorsten Leemhuis) Sept. 5, 2023, 1:22 p.m. UTC | #8

[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]

On 31.08.23 20:24, Thorsten Leemhuis wrote:
> On 31.08.23 19:59, Nick Desaulniers wrote:
>> On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis
>> <[e-mail]> wrote:
>>>
>>> On 31.08.23 19:17, Conor Dooley wrote:
>>>> On Thu, Aug 31, 2023 at 10:05:04AM -0700, Nick Desaulniers wrote:
>>>>> On Fri, Aug 25, 2023 at 05:02:46AM +0000, Andy Chiu wrote:
>>>>>> This patch add back the ptrace support with the following fix:
>>>>>>  - Define NT_RISCV_CSR and re-number NT_RISCV_VECTOR to prevent
>>>>>>    conflicting with gdb's NT_RISCV_CSR.
>>>>>>  - Use struct __riscv_v_regset_state to handle ptrace requests
>>>>>>
>>>>> Hi Andy, this is causing an instance of -Wunused-variable. PTAL.
> [...]
>>> You mean the commit-id of the change currently known as dbe46b094026
>>> will change? 

That happened in between and the fix was folded in, so tell regzbot this
was resolved:

#regzbot resolve: culprit updated and fix was folded in (currently known
as 9300f0043974)
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

Patch

diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h
index 283800130614..575e95bb1bc3 100644
--- a/arch/riscv/include/uapi/asm/ptrace.h
+++ b/arch/riscv/include/uapi/asm/ptrace.h
@@ -103,13 +103,18 @@  struct __riscv_v_ext_state {
 	 * In signal handler, datap will be set a correct user stack offset
 	 * and vector registers will be copied to the address of datap
 	 * pointer.
-	 *
-	 * In ptrace syscall, datap will be set to zero and the vector
-	 * registers will be copied to the address right after this
-	 * structure.
 	 */
 };
 
+struct __riscv_v_regset_state {
+	unsigned long vstart;
+	unsigned long vl;
+	unsigned long vtype;
+	unsigned long vcsr;
+	unsigned long vlenb;
+	char vreg[];
+};
+
 /*
  * According to spec: The number of bits in a single vector register,
  * VLEN >= ELEN, which must be a power of 2, and must be no greater than
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 487303e3ef22..9a87e5d490b5 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -25,6 +25,9 @@  enum riscv_regset {
 #ifdef CONFIG_FPU
 	REGSET_F,
 #endif
+#ifdef CONFIG_RISCV_ISA_V
+	REGSET_V,
+#endif
 };
 
 static int riscv_gpr_get(struct task_struct *target,
@@ -81,6 +84,71 @@  static int riscv_fpr_set(struct task_struct *target,
 }
 #endif
 
+#ifdef CONFIG_RISCV_ISA_V
+static int riscv_vr_get(struct task_struct *target,
+			const struct user_regset *regset,
+			struct membuf to)
+{
+	struct __riscv_v_ext_state *vstate = &target->thread.vstate;
+	struct __riscv_v_regset_state ptrace_vstate;
+
+	if (!riscv_v_vstate_query(task_pt_regs(target)))
+		return -EINVAL;
+
+	/*
+	 * Ensure the vector registers have been saved to the memory before
+	 * copying them to membuf.
+	 */
+	if (target == current)
+		riscv_v_vstate_save(current, task_pt_regs(current));
+
+	ptrace_vstate.vstart = vstate->vstart;
+	ptrace_vstate.vl = vstate->vl;
+	ptrace_vstate.vtype = vstate->vtype;
+	ptrace_vstate.vcsr = vstate->vcsr;
+	ptrace_vstate.vlenb = vstate->vlenb;
+
+	/* Copy vector header from vstate. */
+	membuf_write(&to, &ptrace_vstate, sizeof(struct __riscv_v_regset_state));
+
+	/* Copy all the vector registers from vstate. */
+	return membuf_write(&to, vstate->datap, riscv_v_vsize);
+}
+
+static int riscv_vr_set(struct task_struct *target,
+			const struct user_regset *regset,
+			unsigned int pos, unsigned int count,
+			const void *kbuf, const void __user *ubuf)
+{
+	int ret, size;
+	struct __riscv_v_ext_state *vstate = &target->thread.vstate;
+	struct __riscv_v_regset_state ptrace_vstate;
+
+	if (!riscv_v_vstate_query(task_pt_regs(target)))
+		return -EINVAL;
+
+	/* Copy rest of the vstate except datap */
+	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &ptrace_vstate, 0,
+				 sizeof(struct __riscv_v_regset_state));
+	if (unlikely(ret))
+		return ret;
+
+	if (vstate->vlenb != ptrace_vstate.vlenb)
+		return -EINVAL;
+
+	vstate->vstart = ptrace_vstate.vstart;
+	vstate->vl = ptrace_vstate.vl;
+	vstate->vtype = ptrace_vstate.vtype;
+	vstate->vcsr = ptrace_vstate.vcsr;
+
+	/* Copy all the vector registers. */
+	pos = 0;
+	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, vstate->datap,
+				 0, riscv_v_vsize);
+	return ret;
+}
+#endif
+
 static const struct user_regset riscv_user_regset[] = {
 	[REGSET_X] = {
 		.core_note_type = NT_PRSTATUS,
@@ -100,6 +168,17 @@  static const struct user_regset riscv_user_regset[] = {
 		.set = riscv_fpr_set,
 	},
 #endif
+#ifdef CONFIG_RISCV_ISA_V
+	[REGSET_V] = {
+		.core_note_type = NT_RISCV_VECTOR,
+		.align = 16,
+		.n = ((32 * RISCV_MAX_VLENB) +
+		      sizeof(struct __riscv_v_regset_state)) / sizeof(__u32),
+		.size = sizeof(__u32),
+		.regset_get = riscv_vr_get,
+		.set = riscv_vr_set,
+	},
+#endif
 };
 
 static const struct user_regset_view riscv_user_native_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index e0e159138331..20e285fdbc46 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -443,6 +443,8 @@  typedef struct elf64_shdr {
 #define NT_MIPS_DSP	0x800		/* MIPS DSP ASE registers */
 #define NT_MIPS_FP_MODE	0x801		/* MIPS floating-point mode */
 #define NT_MIPS_MSA	0x802		/* MIPS SIMD registers */
+#define NT_RISCV_CSR	0x900		/* RISC-V Control and Status Registers */
+#define NT_RISCV_VECTOR	0x901		/* RISC-V vector registers */
 #define NT_LOONGARCH_CPUCFG	0xa00	/* LoongArch CPU config registers */
 #define NT_LOONGARCH_CSR	0xa01	/* LoongArch control and status registers */
 #define NT_LOONGARCH_LSX	0xa02	/* LoongArch Loongson SIMD Extension registers */