* Re: [v2] RISC-V: Add ptrace support for vectors
[not found] <20230825050248.32681-1-andy.chiu@sifive.com>
@ 2023-08-31 17:05 ` Nick Desaulniers
2023-08-31 17:17 ` Conor Dooley
0 siblings, 1 reply; 6+ messages in thread
From: Nick Desaulniers @ 2023-08-31 17:05 UTC (permalink / raw)
To: Andy Chiu
Cc: linux-riscv, palmer, greentime.hu, guoren,
20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley, Albert Ou,
Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan, regressions
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]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v2] RISC-V: Add ptrace support for vectors
2023-08-31 17:05 ` [v2] RISC-V: Add ptrace support for vectors Nick Desaulniers
@ 2023-08-31 17:17 ` Conor Dooley
2023-08-31 17:50 ` Thorsten Leemhuis
0 siblings, 1 reply; 6+ messages in thread
From: Conor Dooley @ 2023-08-31 17:17 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Andy Chiu, linux-riscv, palmer, greentime.hu, guoren,
20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley, Albert Ou,
Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan, regressions
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v2] RISC-V: Add ptrace support for vectors
2023-08-31 17:17 ` Conor Dooley
@ 2023-08-31 17:50 ` Thorsten Leemhuis
2023-08-31 17:59 ` Nick Desaulniers
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Leemhuis @ 2023-08-31 17:50 UTC (permalink / raw)
To: Conor Dooley, Nick Desaulniers
Cc: Andy Chiu, linux-riscv, palmer, greentime.hu, guoren,
20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley, Albert Ou,
Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v2] RISC-V: Add ptrace support for vectors
2023-08-31 17:50 ` Thorsten Leemhuis
@ 2023-08-31 17:59 ` Nick Desaulniers
2023-08-31 18:24 ` Thorsten Leemhuis
0 siblings, 1 reply; 6+ messages in thread
From: Nick Desaulniers @ 2023-08-31 17:59 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Conor Dooley, Andy Chiu, linux-riscv, palmer, greentime.hu,
guoren, 20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley,
Albert Ou, Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan
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.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v2] RISC-V: Add ptrace support for vectors
2023-08-31 17:59 ` Nick Desaulniers
@ 2023-08-31 18:24 ` Thorsten Leemhuis
2023-09-05 13:22 ` Linux regression tracking #update (Thorsten Leemhuis)
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Leemhuis @ 2023-08-31 18:24 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Conor Dooley, Andy Chiu, linux-riscv, palmer, greentime.hu,
guoren, 20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley,
Albert Ou, Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v2] RISC-V: Add ptrace support for vectors
2023-08-31 18:24 ` Thorsten Leemhuis
@ 2023-09-05 13:22 ` Linux regression tracking #update (Thorsten Leemhuis)
0 siblings, 0 replies; 6+ messages in thread
From: Linux regression tracking #update (Thorsten Leemhuis) @ 2023-09-05 13:22 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Conor Dooley, Andy Chiu, linux-riscv, palmer, greentime.hu,
guoren, 20230816155450.26200-4-andy.chiu, bjorn, Paul Walmsley,
Albert Ou, Oleg Nesterov, Eric Biederman, Kees Cook, Vincent Chen,
Heiko Stuebner, Conor Dooley, Benjamin Gray, Qing Zhang,
Baruch Siach, Rolf Eike Beer, llvm, nathan
[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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-05 13:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230825050248.32681-1-andy.chiu@sifive.com>
2023-08-31 17:05 ` [v2] RISC-V: Add ptrace support for vectors Nick Desaulniers
2023-08-31 17:17 ` Conor Dooley
2023-08-31 17:50 ` Thorsten Leemhuis
2023-08-31 17:59 ` Nick Desaulniers
2023-08-31 18:24 ` Thorsten Leemhuis
2023-09-05 13:22 ` Linux regression tracking #update (Thorsten Leemhuis)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox