| Message ID | 20230825050248.32681-1-andy.chiu@sifive.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | dbe46b0940261301a038bbe1d699b29158b35a8d |
| Headers | show |
| Series | [v2] RISC-V: Add ptrace support for vectors | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/cover_letter | success | Single patches do not need cover letters |
| conchuod/tree_selection | success | Guessed tree name to be fixes at HEAD ef21fa7c198e |
| conchuod/fixes_present | success | Fixes tag present in non-next series |
| conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 4 and now 4 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/build_rv64_clang_allmodconfig | success | Errors and warnings before: 2810 this patch: 2810 |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/build_rv64_gcc_allmodconfig | success | Errors and warnings before: 15873 this patch: 15872 |
| conchuod/build_rv32_defconfig | success | Build OK |
| conchuod/dtb_warn_rv64 | success | Errors and warnings before: 12 this patch: 12 |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 127 lines checked |
| conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
| conchuod/verify_fixes | success | Fixes tag looks correct |
| conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
Hello: This patch was applied to riscv/linux.git (for-next) by Palmer Dabbelt <palmer@rivosinc.com>: 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!
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 <andy.chiu@sifive.com> Hi Andy, this is causing an instance of -Wunused-variable. PTAL. Please use the following tags on the fix: Reported-by: "kernelci.org bot" <bot@kernelci.org> Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ 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]
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 <andy.chiu@sifive.com> > > Hi Andy, this is causing an instance of -Wunused-variable. PTAL. > > Please use the following tags on the fix: > > Reported-by: "kernelci.org bot" <bot@kernelci.org> > Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ > > Let's see if I can get the regzbot tag correct; first time trying it. > > #regzbot introduced dbe46b094026 See <20230830203754.24940-1-palmer@rivosinc.com> 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.
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 <andy.chiu@sifive.com> >> >> Hi Andy, this is causing an instance of -Wunused-variable. PTAL. >> >> Please use the following tags on the fix: >> >> Reported-by: "kernelci.org bot" <bot@kernelci.org> >> Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ >> >> 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 ZPDIQEVaEJHXR5IW@google.com) 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/ZPDIQEVaEJHXR5IW@google.com/ 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 64f03ea1.170a0220.d3dbf.11fd@mx.google.com is a duplicate of ZPDIQEVaEJHXR5IW@google.com: #regzbot dup-of: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ 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 <20230830203754.24940-1-palmer@rivosinc.com> 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
On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis <regressions@leemhuis.info> 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 <andy.chiu@sifive.com> > >> > >> Hi Andy, this is causing an instance of -Wunused-variable. PTAL. > >> > >> Please use the following tags on the fix: > >> > >> Reported-by: "kernelci.org bot" <bot@kernelci.org> > >> Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ > >> > >> 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 ZPDIQEVaEJHXR5IW@google.com) 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/ZPDIQEVaEJHXR5IW@google.com/ > > 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/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ 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 64f03ea1.170a0220.d3dbf.11fd@mx.google.com > is a duplicate of ZPDIQEVaEJHXR5IW@google.com: > > #regzbot dup-of: > https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ 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 <20230830203754.24940-1-palmer@rivosinc.com> 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.
On 31.08.23 19:59, Nick Desaulniers wrote: > On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis > <regressions@leemhuis.info> 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 <andy.chiu@sifive.com> >>>> >>>> Hi Andy, this is causing an instance of -Wunused-variable. PTAL. >>>> >>>> Please use the following tags on the fix: >>>> >>>> Reported-by: "kernelci.org bot" <bot@kernelci.org> >>>> Closes: https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ >>>> >>>> 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 ZPDIQEVaEJHXR5IW@google.com) 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/ZPDIQEVaEJHXR5IW@google.com/ >> >> 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/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ > 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 64f03ea1.170a0220.d3dbf.11fd@mx.google.com >> is a duplicate of ZPDIQEVaEJHXR5IW@google.com: >> >> #regzbot dup-of: >> https://lore.kernel.org/linux-next/64f03ea1.170a0220.d3dbf.11fd@mx.google.com/ > > 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 <20230830203754.24940-1-palmer@rivosinc.com> 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
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,
[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 >> <regressions@leemhuis.info> 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.
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 */
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 <andy.chiu@sifive.com> --- 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(-)