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

[Nick Desaulniers]

On Thu, Aug 31, 2023 at 10:50 AM Thorsten Leemhuis
<regressions at 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 at 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 at 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 at 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 at mx.google.com
> is a duplicate of ZPDIQEVaEJHXR5IW at 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 at 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.
-- 
Thanks,
~Nick Desaulniers