Greeting,
FYI, we noticed the following commit (built with gcc-11):
commit: c3e0c8c2e8b17bae30d5978bc2decdd4098f0f99 ("KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: leaking-addresses
version: leaking-addresses-x86_64-4f19048-1_20220518
with following parameters:
ucode: 0x28
on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
below (1) is not observed on parent:
2022-08-13 10:24:37 ./leaking_addresses.pl --output-raw result/scan.out
2022-08-13 10:25:04 ./leaking_addresses.pl --input-raw result/scan.out --squash-by-filename
Total number of results from scan (incl dmesg): 169358
dmesg output:
[ 2.194330] mapped IOAPIC to ffffffffff5fb000 (fec00000)
Results squashed by filename (excl dmesg). Displaying [<number of results> <filename>], <example result>
[18 __ksymtab_gpl] 0xffffffffa07ae054
[49 .text] 0xffffffffa03e7000
[20 .altinstr_replacement] 0xffffffffa07adacf
[2 6] inotify wd:18 ino:1ff sdev:19 mask:2 ignored_mask:0 fhandle-bytes:8 fhandle-type:fe f_handle:ff01000000000000
[18 __dyndbg] 0xffffffffa03f04e0
[34 .retpoline_sites] 0xffffffffa04044b7
[14 .parainstructions] 0xffffffffa07b0ed0
[48 .text.startup] 0xffffffffa03ea200
[7 .static_call_sites] 0xffffffffa11c75f8
[6 .ref.data] 0xffffffffa04d8dc0
[48 .fini_array] 0xffffffffa03f0520
[49 .symtab] 0xffffffffa0277000
[20 __param] 0xffffffffa03eba88
[35 .text.unlikely] 0xffffffffa03ea0ae
[49 .strtab] 0xffffffffa0277de0
[6 __bpf_raw_tp_map] 0xffffffffa04d8d40
[1 ___srcu_struct_ptrs] 0xffffffffa0381580
[49 .return_sites] 0xffffffffa03ebf50
[4 .altinstr_aux] 0xffffffffa0ab2b58
[6 __tracepoints_ptrs] 0xffffffffa04cb0dc
[25 .smp_locks] 0xffffffffa03eba80
[167298 kallsyms] ffffffff81000000 T startup_64
[329 blacklist] 0xffffffff838008f0-0xffffffff83800910 asm_exc_divide_error
[2 .rodata.cst16.bswap_mask] 0xffffffffa03d2100
[2 .noinstr.text] 0xffffffffa0ab3c00
[49 .note.gnu.build-id] 0xffffffffa03eb000
[34 .bss] 0xffffffffa03f08c0
[10 __ex_table] 0xffffffffa0458720
[20 .altinstructions] 0xffffffffa07b0eec
[2 _ftrace_eval_map] 0xffffffffa11c4e48
[6 .static_call.text] 0xffffffffa04b878c
[1 _error_injection_whitelist] 0xffffffffa11cdc90
[41 .rodata.str1.8] 0xffffffffa03eb058
[26 __bug_table] 0xffffffffa06d9720
[48 .init_array] 0xffffffffa0276000
[49 .gnu.linkonce.this_module] 0xffffffffa03f0540
[9 .init.rodata] 0xffffffffa0275000
[25 __jump_table] 0xffffffffa03ed000
[6 __tracepoints] 0xffffffffa04d8ee0
[33 .exit.text] 0xffffffffa03ea181
[48 .rodata.str1.1] 0xffffffffa03ebab0
[48 .text.exit] 0xffffffffa03ea1c0
[49 .orc_unwind] 0xffffffffa03ebf84
[6 _ftrace_events] 0xffffffffa04d8da0
[49 .note.Linux] 0xffffffffa03eb024
[1 .rodata.cst16.mask1] 0xffffffffa040c120
[296 printk_formats] 0xffffffff83c6bd20 : "CPU_ON"
[46 __mcount_loc] 0xffffffffa03eba20
[1 .data..ro_after_init] 0xffffffffa0b32250 <---------- (1)
[6 __tracepoints_strings] 0xffffffffa04cb0f0
[37 .init.text] 0xffffffffa0274000
[22 __ksymtab] 0xffffffffa0404054
[11 .data..read_mostly] 0xffffffffa03f0518
[49 .orc_unwind_ip] 0xffffffffa03ec3c8
[5 .init.data] 0xffffffffa0429000
[48 .data] 0xffffffffa03ee000
[49 modules] btrfs 4456448 1 - Live 0xffffffffa0dce000
[1 .rodata.cst32.byteshift_table] 0xffffffffa040c150
[9 .data.once] 0xffffffffa077a964
[30 __ksymtab_strings] 0xffffffffa0404060
[1 .rodata.cst16.mask2] 0xffffffffa040c130
[47 .rodata] 0xffffffffa03eb100
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
sudo bin/lkp install job.yaml # job file is attached in this email
bin/lkp split-job --compatible job.yaml # generate the yaml file for lkp run
sudo bin/lkp run generated-yaml-file
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
#regzbot introduced: c3e0c8c2e8
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Hi, this is your Linux kernel regression tracker.
On 15.08.22 16:34, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-11):
>
> commit: c3e0c8c2e8b17bae30d5978bc2decdd4098f0f99 ("KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: leaking-addresses
> version: leaking-addresses-x86_64-4f19048-1_20220518
> with following parameters:
>
> ucode: 0x28
>
>
>
> on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <[email protected]>
>
> [...]
>
> #regzbot introduced: c3e0c8c2e8
Removing this from the list of tracked regressions:
#regzbot invalid: report from the kernel test report that was ignored by
developers, so I assume it's not something bad
To explain: Yeah, maybe tracking regressions found by CI systems in
regzbot might be a good idea now or in the long run. If you are from
Intel and would like to discuss how to do this, please get in touch (I
tried recently, but got no answer[1]).
But I'm not sure if it's a good idea right now to get regzbot involved
by default (especially as long as the reports are not telling developers
to add proper "Link:" tags that would allow regzbot to notice when fixes
for the problem are posted or merged; see [1] and [2]), as it looks like
developers ignore quite a few (many?) reports like the one partly quoted
above.
I guess there are various reasons why developers do so (too many false
positives? issues unlikely to happen in practice? already fixed?).
Normally I'd say "this is a regression and I should try to find out and
prod developers to get it fixed". And I'll do that if the issue
obviously looks important to a Linux kernel generalist like me.
But that doesn't appear to be the case here (please correct me if I
misjudged!). I hence chose to ignore this report, as there are quite a
few other reports that are waiting for my attention, too. :-/
Ciao, Thorsten
[1]
https://lore.kernel.org/all/[email protected]/
[2] https://docs.kernel.org/process/handling-regressions.html
On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker.
>
> On 15.08.22 16:34, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-11):
> >
> > commit: c3e0c8c2e8b17bae30d5978bc2decdd4098f0f99 ("KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: leaking-addresses
> > version: leaking-addresses-x86_64-4f19048-1_20220518
> > with following parameters:
> >
> > ucode: 0x28
> >
> >
> >
> > on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G memory
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot <[email protected]>
> >
> > [...]
> >
> > #regzbot introduced: c3e0c8c2e8
>
> Removing this from the list of tracked regressions:
>
> #regzbot invalid: report from the kernel test report that was ignored by
> developers, so I assume it's not something bad
>
> To explain: Yeah, maybe tracking regressions found by CI systems in
> regzbot might be a good idea now or in the long run. If you are from
> Intel and would like to discuss how to do this, please get in touch (I
> tried recently, but got no answer[1]).
Sorry, this was a mistake that we missed [1] to provide our reply. I will
reply to the questions in that one soon.
>
> But I'm not sure if it's a good idea right now to get regzbot involved
> by default (especially as long as the reports are not telling developers
> to add proper "Link:" tags that would allow regzbot to notice when fixes
Apologize again that we started to track mainline regression we found before
we fully understand [2], which probably not the effective usage. Especially
we missed the initial touch and led to more improper usage.
> for the problem are posted or merged; see [1] and [2]), as it looks like
> developers ignore quite a few (many?) reports like the one partly quoted
> above.
>
> I guess there are various reasons why developers do so (too many false
> positives? issues unlikely to happen in practice? already fixed?).
agree, not all reports we send out got response even it was reported on
mainline (0day does wide range testing include the repos from developer,
so the reports are against these repos and mainline/next).
Usuaally, we also ping/discuss with developer when an issue enters
mainline if there's no response. This is one reason we tries to connect
with regzbot to track the issue on mainline, but we missed the point that
you mention below (it need look important).
> Normally I'd say "this is a regression and I should try to find out and
> prod developers to get it fixed". And I'll do that if the issue
> obviously looks important to a Linux kernel generalist like me.
got it, thanks for the info, i found earlier you tracked a bug from kernel
test robot, which should be the case that you thought it was important.
>
> But that doesn't appear to be the case here (please correct me if I
> misjudged!). I hence chose to ignore this report, as there are quite a
> few other reports that are waiting for my attention, too. :-/
Thanks, we will revisit our process and consult you before we do any actual
action, and sorry for causing you extra effort to do cleanup.
>
> Ciao, Thorsten
>
> [1]
> https://lore.kernel.org/all/[email protected]/
>
>
> [2] https://docs.kernel.org/process/handling-regressions.html
> _______________________________________________
> LKP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
On 01.09.22 15:24, Philip Li wrote:
> On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker.
>>
>> On 15.08.22 16:34, kernel test robot wrote:
>>> Greeting,
>>>
>>> FYI, we noticed the following commit (built with gcc-11):
>>>
>>> commit: c3e0c8c2e8b17bae30d5978bc2decdd4098f0f99 ("KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change")
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>>
>>> in testcase: leaking-addresses
>>> version: leaking-addresses-x86_64-4f19048-1_20220518
>>> with following parameters:
>>>
>>> ucode: 0x28
>>>
>>> on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G memory
>>>
>>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>>>
>>> If you fix the issue, kindly add following tag
>>> Reported-by: kernel test robot <[email protected]>
>>>
>>> [...]
>>>
>>> #regzbot introduced: c3e0c8c2e8
>>
>> Removing this from the list of tracked regressions:
>>
>> #regzbot invalid: report from the kernel test report that was ignored by
>> developers, so I assume it's not something bad
>>
>> To explain: Yeah, maybe tracking regressions found by CI systems in
>> regzbot might be a good idea now or in the long run. If you are from
>> Intel and would like to discuss how to do this, please get in touch (I
>> tried recently, but got no answer[1]).
>
> Sorry, this was a mistake that we missed [1] to provide our reply. I will
> reply to the questions in that one soon.
Thx!
>> But I'm not sure if it's a good idea right now to get regzbot involved
>> by default (especially as long as the reports are not telling developers
>> to add proper "Link:" tags that would allow regzbot to notice when fixes
>
> Apologize again that we started to track mainline regression we found before
> we fully understand [2], which probably not the effective usage. Especially
> we missed the initial touch and led to more improper usage.
No worries, as maybe it's a good thing to have the 0day reports in
there, even if some of its reports don't get any traction. But having
them in the list of tracked regressions gives them some more visibility
for a while -- and at least one more set of eyes (mine) that take a look
at it. And it's not that much work for me or anybody else to close the
issue in regzbot (say after a week or two) if no developer acts on it
because it's irrelevant from their point of view. But would still be
better if they'd state that publicly themselves; in that case they even
could tell regzbot to ignore the issue; your report's could tell people
how to do that (e.g. "#regzbot invalid some_reason").
>> for the problem are posted or merged; see [1] and [2]), as it looks like
>> developers ignore quite a few (many?) reports like the one partly quoted
>> above.
>>
>> I guess there are various reasons why developers do so (too many false
>> positives? issues unlikely to happen in practice? already fixed?).
>
> agree, not all reports we send out got response even it was reported on
> mainline (0day does wide range testing include the repos from developer,
> so the reports are against these repos and mainline/next).
>
> Usuaally, we also ping/discuss with developer when an issue enters
> mainline if there's no response. This is one reason we tries to connect
> with regzbot to track the issue on mainline, but we missed the point that
> you mention below (it need look important).
I just want to prevent the list of tracked regressions becoming too long
(and thus obscure) due to many issues that are not worth tracking, as I
fear people will then start to ignore regzbot and its reports. :-/
>> Normally I'd say "this is a regression and I should try to find out and
>> prod developers to get it fixed". And I'll do that if the issue
>> obviously looks important to a Linux kernel generalist like me.
>
> got it, thanks for the info, i found earlier you tracked a bug from kernel
> test robot, which should be the case that you thought it was important.
Yeah, some of the reports are valuable, that's why I guess it makes
sense to track at least some of them. The question is, how to filter the
bad ones out or how to pick just the valuable ones...
Are you or someone from the 0day team an LPC? Then we could discuss this
in person there.
>> But that doesn't appear to be the case here (please correct me if I
>> misjudged!). I hence chose to ignore this report, as there are quite a
>> few other reports that are waiting for my attention, too. :-/
>
> Thanks, we will revisit our process and consult you before we do any actual
> action, and sorry for causing you extra effort to do cleanup.
No need to be sorry, everything is fine, up to some point I liked what
you did. :-D
Ciao, Thorsten
On Fri, Sep 02, 2022 at 12:54:05PM +0200, Thorsten Leemhuis wrote:
> On 01.09.22 15:24, Philip Li wrote:
> > On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
> >> Hi, this is your Linux kernel regression tracker.
> >>
> >> On 15.08.22 16:34, kernel test robot wrote:
> >>> Greeting,
> >>>
> >>> FYI, we noticed the following commit (built with gcc-11):
> >>>
> >>> commit: c3e0c8c2e8b17bae30d5978bc2decdd4098f0f99 ("KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change")
> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >>>
> >>> in testcase: leaking-addresses
> >>> version: leaking-addresses-x86_64-4f19048-1_20220518
> >>> with following parameters:
> >>>
> >>> ucode: 0x28
> >>>
> >>> on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with 16G memory
> >>>
> >>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
> >>>
> >>> If you fix the issue, kindly add following tag
> >>> Reported-by: kernel test robot <[email protected]>
> >>>
> >>> [...]
> >>>
> >>> #regzbot introduced: c3e0c8c2e8
> >>
> >> Removing this from the list of tracked regressions:
> >>
> >> #regzbot invalid: report from the kernel test report that was ignored by
> >> developers, so I assume it's not something bad
> >>
> >> To explain: Yeah, maybe tracking regressions found by CI systems in
> >> regzbot might be a good idea now or in the long run. If you are from
> >> Intel and would like to discuss how to do this, please get in touch (I
> >> tried recently, but got no answer[1]).
> >
> > Sorry, this was a mistake that we missed [1] to provide our reply. I will
> > reply to the questions in that one soon.
>
> Thx!
>
> >> But I'm not sure if it's a good idea right now to get regzbot involved
> >> by default (especially as long as the reports are not telling developers
> >> to add proper "Link:" tags that would allow regzbot to notice when fixes
> >
> > Apologize again that we started to track mainline regression we found before
> > we fully understand [2], which probably not the effective usage. Especially
> > we missed the initial touch and led to more improper usage.
>
> No worries, as maybe it's a good thing to have the 0day reports in
> there, even if some of its reports don't get any traction. But having
> them in the list of tracked regressions gives them some more visibility
> for a while -- and at least one more set of eyes (mine) that take a look
> at it. And it's not that much work for me or anybody else to close the
> issue in regzbot (say after a week or two) if no developer acts on it
> because it's irrelevant from their point of view. But would still be
> better if they'd state that publicly themselves; in that case they even
> could tell regzbot to ignore the issue; your report's could tell people
> how to do that (e.g. "#regzbot invalid some_reason").
Thanks for the encouragement :-) The flow/process is very helpful. We will follow
up a few things before we resuming the tracking
1) Add Link tag
2) Do internal judgement of mainline regression we found for whether it is
important, so we do some filtering at initial period to avoid bringing noise to the list.
3) Add the hint as you suggested here, so it can be easily invalidate by developer.
Also some thinking below.
>
> >> for the problem are posted or merged; see [1] and [2]), as it looks like
> >> developers ignore quite a few (many?) reports like the one partly quoted
> >> above.
> >>
> >> I guess there are various reasons why developers do so (too many false
> >> positives? issues unlikely to happen in practice? already fixed?).
> >
> > agree, not all reports we send out got response even it was reported on
> > mainline (0day does wide range testing include the repos from developer,
> > so the reports are against these repos and mainline/next).
> >
> > Usuaally, we also ping/discuss with developer when an issue enters
> > mainline if there's no response. This is one reason we tries to connect
> > with regzbot to track the issue on mainline, but we missed the point that
> > you mention below (it need look important).
>
> I just want to prevent the list of tracked regressions becoming too long
> (and thus obscure) due to many issues that are not worth tracking, as I
> fear people will then start to ignore regzbot and its reports. :-/
got it, we will be very careful to selectly tracking. Maybe we don't need
track the issue if it is responsed by developer quickly and can be solved
directly.
But only track the one that is valuable, while it need more discussion, extra
testing, investigation and so one, that such problem can't be straight forward
to solve in short time. For such case, the tracking helps us to get back to this
even when there's a pause, like developer is blocked by testing or need switch
to other effort. This is just my thinking.
>
> >> Normally I'd say "this is a regression and I should try to find out and
> >> prod developers to get it fixed". And I'll do that if the issue
> >> obviously looks important to a Linux kernel generalist like me.
> >
> > got it, thanks for the info, i found earlier you tracked a bug from kernel
> > test robot, which should be the case that you thought it was important.
>
> Yeah, some of the reports are valuable, that's why I guess it makes
> sense to track at least some of them. The question is, how to filter the
> bad ones out or how to pick just the valuable ones...
Currently what in my mind is we will consider performance regression like
around or larger than 10% for certain test case, or some general tests such
as kselftests, or serious boot issue.
Or if you considers certain reports are valuable and track them, we will also
learn from this to get better understanding of what worth tracking now.
>
> Are you or someone from the 0day team an LPC? Then we could discuss this
> in person there.
We will join 2 MC (Rust, Testing) but all virtually, thus not able to discuss in
person :-( But we are glad to join any further discussion or follow the suggested
rule if you have some discussion with other CI and reporters.
>
> >> But that doesn't appear to be the case here (please correct me if I
> >> misjudged!). I hence chose to ignore this report, as there are quite a
> >> few other reports that are waiting for my attention, too. :-/
> >
> > Thanks, we will revisit our process and consult you before we do any actual
> > action, and sorry for causing you extra effort to do cleanup.
>
> No need to be sorry, everything is fine, up to some point I liked what
> you did. :-D
>
> Ciao, Thorsten
On 02.09.22 14:26, Philip Li wrote:
> On Fri, Sep 02, 2022 at 12:54:05PM +0200, Thorsten Leemhuis wrote:
>> On 01.09.22 15:24, Philip Li wrote:
>>> On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
>
> [...]
>
> Thanks for the encouragement :-) The flow/process is very helpful. We will follow
> up a few things before we resuming the tracking
> [...]
Great, thx!
>>> Usuaally, we also ping/discuss with developer when an issue enters
>>> mainline if there's no response. This is one reason we tries to connect
>>> with regzbot to track the issue on mainline, but we missed the point that
>>> you mention below (it need look important).
>>
>> I just want to prevent the list of tracked regressions becoming too long
>> (and thus obscure) due to many issues that are not worth tracking, as I
>> fear people will then start to ignore regzbot and its reports. :-/
>
> got it, we will be very careful to selectly tracking. Maybe we don't need
> track the issue if it is responsed by developer quickly and can be solved
> directly.
Maybe, but that will always bear the risk that something gets in the way
(say a big problem is found in the proposed fix) and the regression in
the end gets forgotten and remains unfixed -- which my tracking tries to
prevent. Hence I'd say doing it the other way around (adding all
regressions reported by the 0-day folks to regzbot and remove reports
after a week or two if it's apparently something that can be ignored)
would be the better approach.
> But only track the one that is valuable, while it need more discussion, extra
> testing, investigation and so one, that such problem can't be straight forward
> to solve in short time. For such case, the tracking helps us to get back to this
> even when there's a pause, like developer is blocked by testing or need switch
> to other effort. This is just my thinking.
Yeah, the problem is just: it's easy to forget the regression to the
tracking. :-/
>> Are you or someone from the 0day team an LPC? Then we could discuss this
>> in person there.
>
> We will join 2 MC (Rust, Testing) but all virtually, thus not able to discuss in
> person :-(
Okay, was worth asking. :-D
> But we are glad to join any further discussion or follow the suggested
> rule if you have some discussion with other CI and reporters.
Yeah, I'm pretty sure we'll find a way to make everybody happy.
Ciao, Thorsten
On Sat, Sep 03, 2022 at 12:27:19PM +0200, Thorsten Leemhuis wrote:
> On 02.09.22 14:26, Philip Li wrote:
> > On Fri, Sep 02, 2022 at 12:54:05PM +0200, Thorsten Leemhuis wrote:
> >> On 01.09.22 15:24, Philip Li wrote:
> >>> On Thu, Sep 01, 2022 at 02:12:39PM +0200, Thorsten Leemhuis wrote:
> >
> > [...]
> >
> > Thanks for the encouragement :-) The flow/process is very helpful. We will follow
> > up a few things before we resuming the tracking
> > [...]
>
> Great, thx!
>
> >>> Usuaally, we also ping/discuss with developer when an issue enters
> >>> mainline if there's no response. This is one reason we tries to connect
> >>> with regzbot to track the issue on mainline, but we missed the point that
> >>> you mention below (it need look important).
> >>
> >> I just want to prevent the list of tracked regressions becoming too long
> >> (and thus obscure) due to many issues that are not worth tracking, as I
> >> fear people will then start to ignore regzbot and its reports. :-/
> >
> > got it, we will be very careful to selectly tracking. Maybe we don't need
> > track the issue if it is responsed by developer quickly and can be solved
> > directly.
>
> Maybe, but that will always bear the risk that something gets in the way
> (say a big problem is found in the proposed fix) and the regression in
> the end gets forgotten and remains unfixed -- which my tracking tries to
> prevent. Hence I'd say doing it the other way around (adding all
> regressions reported by the 0-day folks to regzbot and remove reports
> after a week or two if it's apparently something that can be ignored)
> would be the better approach.
Got it, we will follow this approach, to track the issue but remove them
after a week or two.
>
> > But only track the one that is valuable, while it need more discussion, extra
> > testing, investigation and so one, that such problem can't be straight forward
> > to solve in short time. For such case, the tracking helps us to get back to this
> > even when there's a pause, like developer is blocked by testing or need switch
> > to other effort. This is just my thinking.
>
> Yeah, the problem is just: it's easy to forget the regression to the
> tracking. :-/
>
> >> Are you or someone from the 0day team an LPC? Then we could discuss this
> >> in person there.
> >
> > We will join 2 MC (Rust, Testing) but all virtually, thus not able to discuss in
> > person :-(
>
> Okay, was worth asking. :-D
>
> > But we are glad to join any further discussion or follow the suggested
> > rule if you have some discussion with other CI and reporters.
>
> Yeah, I'm pretty sure we'll find a way to make everybody happy.
>
> Ciao, Thorsten