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

[Thorsten Leemhuis]

On 31.08.23 19:59, Nick Desaulniers wrote:
> 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.

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 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.

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 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?"

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