RE: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

RE: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Si, Beibei]

#regzbot ^introduced efcfec579f
#regzbot title [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail

> -----Original Message-----
> From: Sang, Oliver <oliver.sang@intel.com>
> Sent: Monday, August 8, 2022 10:42 PM
> To: Darrick J. Wong <darrick.wong@oracle.com>
> Cc: Jens Axboe <axboe@kernel.dk>; Christoph Hellwig <hch@lst.de>; LKML
> <linux-kernel@vger.kernel.org>; linux-block@vger.kernel.org; lkp@lists.01.org;
> lkp <lkp@intel.com>; regressions@lists.linux.dev
> Subject: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail
> 
> 
> (pleased be noted we found the issue still exists on latest maineline, so report
> though the commit is old, FYI)
> 
> 
> Greeting,
> 
> FYI, we noticed the following commit (built with gcc-11):
> 
> commit: efcfec579f6139528c9e6925eca2bc4a36da65c6 ("loop: fix no-unmap
> write-zeroes request behavior")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: mdadm-selftests
> version: mdadm-selftests-x86_64-5f41845-1_20220518
> with following parameters:
> 
> 	disk: 1HDD
> 	test_prefix: 12
> 	ucode: 0x28
> 
> 
> 
> on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz
> 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 <oliver.sang@intel.com>
> 
> 2022-08-05 18:01:28 mkdir -p /var/tmp
> 2022-08-05 18:01:28 mke2fs -t ext3 -b 4096 -J size=4 -q /dev/sda1
> 2022-08-05 18:02:00 mount -t ext3 /dev/sda1 /var/tmp sed -e
> 's/{DEFAULT_METADATA}/1.2/g' \ -e 's,{MAP_PATH},/run/mdadm/map,g'
> mdadm.8.in > mdadm.8 /usr/bin/install -D -m 644 mdadm.8
> /usr/share/man/man8/mdadm.8 /usr/bin/install -D -m 644 mdmon.8
> /usr/share/man/man8/mdmon.8 /usr/bin/install -D -m 644 md.4
> /usr/share/man/man4/md.4 /usr/bin/install -D -m 644 mdadm.conf.5
> /usr/share/man/man5/mdadm.conf.5 /usr/bin/install -D -m 644 udev-md-raid-
> creating.rules /lib/udev/rules.d/01-md-raid-creating.rules
> /usr/bin/install -D -m 644 udev-md-raid-arrays.rules /lib/udev/rules.d/63-md-
> raid-arrays.rules
> /usr/bin/install -D -m 644 udev-md-raid-assembly.rules /lib/udev/rules.d/64-md-
> raid-assembly.rules
> /usr/bin/install -D -m 644 udev-md-clustered-confirm-device.rules
> /lib/udev/rules.d/69-md-clustered-confirm-device.rules
> /usr/bin/install -D  -m 755 mdadm /sbin/mdadm /usr/bin/install -D  -m 755
> mdmon /sbin/mdmon Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r0_2d-grow-r0_3d...
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_3d!
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_3d.log and /var/tmp/fail12imsm-
> r0_2d-grow-r0_3d.log for details Testing on linux-5.4.0-rc2-00010-
> gefcfec579f6139 kernel /lkp/benchmarks/mdadm-selftests/tests/12imsm-
> r0_2d-grow-r0_4d...
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_4d!
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_4d.log and /var/tmp/fail12imsm-
> r0_2d-grow-r0_4d.log for details Testing on linux-5.4.0-rc2-00010-
> gefcfec579f6139 kernel /lkp/benchmarks/mdadm-selftests/tests/12imsm-
> r0_2d-grow-r0_5d...
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_5d!
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_5d.log and /var/tmp/fail12imsm-
> r0_2d-grow-r0_5d.log for details Testing on linux-5.4.0-rc2-00010-
> gefcfec579f6139 kernel /lkp/benchmarks/mdadm-selftests/tests/12imsm-
> r0_3d-grow-r0_4d...
> 	ERROR: dmesg prints errors when testing 12imsm-r0_3d-grow-r0_4d!
> 
> FAILED - see /var/tmp/12imsm-r0_3d-grow-r0_4d.log and /var/tmp/fail12imsm-
> r0_3d-grow-r0_4d.log for details Testing on linux-5.4.0-rc2-00010-
> gefcfec579f6139 kernel /lkp/benchmarks/mdadm-selftests/tests/12imsm-
> r5_3d-grow-r5_4d... succeeded Testing on linux-5.4.0-rc2-00010-
> gefcfec579f6139 kernel /lkp/benchmarks/mdadm-selftests/tests/12imsm-
> r5_3d-grow-r5_5d... succeeded
> 
> 
> 
> 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: efcfec579f
> 
> --
> 0-DAY CI Kernel Test Service
> https://01.org/lkp
> 

Re: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Thorsten Leemhuis]

On 10.08.22 07:44, Si, Beibei wrote:
> #regzbot ^introduced efcfec579f
> #regzbot title [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail

Thx for trying to get regzbot involved, but FWIW, the original mail from
Oliver already did so. :-D Hence let me mark this entry as a duplicate:

#regzbot dup-of:
https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/

While at it something else:

>> -----Original Message-----
>> From: Sang, Oliver <oliver.sang@intel.com>
>> Sent: Monday, August 8, 2022 10:42 PM
>> To: Darrick J. Wong <darrick.wong@oracle.com>
>> Cc: Jens Axboe <axboe@kernel.dk>; Christoph Hellwig <hch@lst.de>; LKML
>> <linux-kernel@vger.kernel.org>; linux-block@vger.kernel.org; lkp@lists.01.org;
>> lkp <lkp@intel.com>; regressions@lists.linux.dev
>> Subject: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail

>> If you fix the issue, kindly add following tag
>> Reported-by: kernel test robot <oliver.sang@intel.com>
>>

Would be really really great if these mails could also directly tell
users to add links tags that point to the report, e.g. in this case the
mail from Oliver that started this thread:

```
 If you fix the issue, kindly add following tag
 Reported-by: kernel test robot <oliver.sang@intel.com>
 Link: https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/
```

Obviously you need the msgid of the mail before you sent it in this
case, but I assume you generate those mails semi-automatically anyway,
so it hopefully won't be too hard to add this.

These tags are considered important by Linus and others, as they allow
anyone to look into the backstory weeks or years later. That is why they
should be placed in cases like this, as
Documentation/process/submitting-patches.rst and
Documentation/process/5.Posting.rst explain in more detail.

I care deeply in the case of 0-bot when the reports contains lines like
this:

>> #regzbot introduced: efcfec579f
That's because regzbot uses the URL in Link: tags to associate patch
postings and commits with reports -- and even automatically closes
regression tracking entries in case a fix linking to a tracked report is
committed to the appropriate tree. A proper "Link:" tag thus saves me a
lot of trouble, as I otherwise have to tell regzbot manually about each
fix for tracked issues, which quickly becomes a PITA. :-/


BTW: I noticed this was not the only recent reports from the kernel test
robot that directly got regzbot involved, but not all do. Is some bot
decising this or a human?

Because the thing is: the time I can spend on tracking regressions is
limited, hence I (at least for now) want to avoid spending any time on
regressions that likely only ever show up in CI testing. But if the
problem is something that is likely to be seen in the wild it's totally
okay for me if you get regzbot involved. FWIWI, it remains to be seen if
that's a good idea in general (and is likely something I will bring up
for discussion on this years kernel summit), but let's just give it a
try. :-D

Ciao, Thorsten

Re: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Philip Li]

On Mon, Aug 15, 2022 at 09:19:30PM +0800, Thorsten Leemhuis wrote:
> On 10.08.22 07:44, Si, Beibei wrote:
> > #regzbot ^introduced efcfec579f
> > #regzbot title [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail
> 
> Thx for trying to get regzbot involved, but FWIW, the original mail from
> Oliver already did so. :-D Hence let me mark this entry as a duplicate:
> 
> #regzbot dup-of:
> https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/
> 
> While at it something else:
> 
> >> -----Original Message-----
> >> From: Sang, Oliver <oliver.sang@intel.com>
> >> Sent: Monday, August 8, 2022 10:42 PM
> >> To: Darrick J. Wong <darrick.wong@oracle.com>
> >> Cc: Jens Axboe <axboe@kernel.dk>; Christoph Hellwig <hch@lst.de>; LKML
> >> <linux-kernel@vger.kernel.org>; linux-block@vger.kernel.org; lkp@lists.01.org;
> >> lkp <lkp@intel.com>; regressions@lists.linux.dev
> >> Subject: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail
> 
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kernel test robot <oliver.sang@intel.com>
> >>
> 
> Would be really really great if these mails could also directly tell
> users to add links tags that point to the report, e.g. in this case the
> mail from Oliver that started this thread:
> 
> ```
>  If you fix the issue, kindly add following tag
>  Reported-by: kernel test robot <oliver.sang@intel.com>
>  Link: https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/
> ```
> 
> Obviously you need the msgid of the mail before you sent it in this
> case, but I assume you generate those mails semi-automatically anyway,
> so it hopefully won't be too hard to add this.

Thanks, this is really great suggestion for us, we will be able to add
this Link tag in future.

> 
> These tags are considered important by Linus and others, as they allow
> anyone to look into the backstory weeks or years later. That is why they
> should be placed in cases like this, as
> Documentation/process/submitting-patches.rst and
> Documentation/process/5.Posting.rst explain in more detail.

Got it, we will learn this again carefully.

> 
> I care deeply in the case of 0-bot when the reports contains lines like
> this:
> 
> >> #regzbot introduced: efcfec579f
> That's because regzbot uses the URL in Link: tags to associate patch
> postings and commits with reports -- and even automatically closes
> regression tracking entries in case a fix linking to a tracked report is
> committed to the appropriate tree. A proper "Link:" tag thus saves me a
> lot of trouble, as I otherwise have to tell regzbot manually about each
> fix for tracked issues, which quickly becomes a PITA. :-/
> 
> 
> BTW: I noticed this was not the only recent reports from the kernel test
> robot that directly got regzbot involved, but not all do. Is some bot
> decising this or a human?

this is controlled by human, we try to connect with regzbot for the regression
we found on mainline. So we add #regzbot after we confirm the issue is valid
on mainline. BTW: 0day does testing on nearly all repos from developer to maintainers
to next and mainline, thus part of them are bisected down to mainline.

> 
> Because the thing is: the time I can spend on tracking regressions is
> limited, hence I (at least for now) want to avoid spending any time on
> regressions that likely only ever show up in CI testing. But if the

got it, probably we need consider a few test suites (and kernel configruations)
that is more "standard", such as kselftests. But this is hard, for example,
we detects performance issue on micro benchmark, and it only shows one perspective
to developer as it may not reflect the use scenario of developer (thus sometimes
it is not reasonable/necessary to fix).

> problem is something that is likely to be seen in the wild it's totally
> okay for me if you get regzbot involved. FWIWI, it remains to be seen if
> that's a good idea in general (and is likely something I will bring up
> for discussion on this years kernel summit), but let's just give it a
> try. :-D

Thanks, we will stop this default behavior to send them directly regzbot. 

I saw one case that you tracked a report from kernel test robot (0day) [1], can i understand
that for now, you will monitor some mailing list and track them when it worths?

BTW: i want to consult that anyone (or CI) else send report to regzbot directly so far?

[1] https://lore.kernel.org/lkml/6b12a0b4-2f6d-1c35-f2e2-a28022583c47@leemhuis.info/

> 
> Ciao, Thorsten

Re: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Thorsten Leemhuis]

TWIMC for those that might not be aware of it: there is a parallel
discussion about the interaction about 0day and regzbot ongoing here:
https://lore.kernel.org/regressions/57c596f7-014f-1833-3173-af3bad2ca45d@leemhuis.info/

On 01.09.22 15:53, Philip Li wrote:
> On Mon, Aug 15, 2022 at 09:19:30PM +0800, Thorsten Leemhuis wrote:
>> On 10.08.22 07:44, Si, Beibei wrote:
> [...]
>> Would be really really great if these mails could also directly tell
>> users to add links tags that point to the report, e.g. in this case the
>> mail from Oliver that started this thread:
>>
>> ```
>>  If you fix the issue, kindly add following tag
>>  Reported-by: kernel test robot <oliver.sang@intel.com>
>>  Link: https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/
>> ```
>>
>> Obviously you need the msgid of the mail before you sent it in this
>> case, but I assume you generate those mails semi-automatically anyway,
>> so it hopefully won't be too hard to add this.
> 
> Thanks, this is really great suggestion for us, we will be able to add
> this Link tag in future.

Great, thx.

> [...]
>> I care deeply in the case of 0-bot when the reports contains lines like
>> this:
>>
>>>> #regzbot introduced: efcfec579f
>> That's because regzbot uses the URL in Link: tags to associate patch
>> postings and commits with reports -- and even automatically closes
>> regression tracking entries in case a fix linking to a tracked report is
>> committed to the appropriate tree. A proper "Link:" tag thus saves me a
>> lot of trouble, as I otherwise have to tell regzbot manually about each
>> fix for tracked issues, which quickly becomes a PITA. :-/
>>
>> BTW: I noticed this was not the only recent reports from the kernel test
>> robot that directly got regzbot involved, but not all do. Is some bot
>> decising this or a human?
> 
> this is controlled by human, we try to connect with regzbot for the regression
> we found on mainline. So we add #regzbot after we confirm the issue is valid
> on mainline.

Okay, good to know. As maybe visible between the lines in the other mail
I linked above already: I guess it's fine that way and we should
continue with this and just see how it goes.

> BTW: 0day does testing on nearly all repos from developer to maintainers
> to next and mainline, thus part of them are bisected down to mainline.

Yeah, I know. Regzbot in principle is handling next as well, but I guess
we should ignore that for now with 0day, as keeping an eye on the
reports against mainline keeps me quite busy already.

>> Because the thing is: the time I can spend on tracking regressions is
>> limited, hence I (at least for now) want to avoid spending any time on
>> regressions that likely only ever show up in CI testing. But if the
> 
> got it, probably we need consider a few test suites (and kernel configruations)
> that is more "standard", such as kselftests. But this is hard, for example,
> we detects performance issue on micro benchmark, and it only shows one perspective
> to developer as it may not reflect the use scenario of developer (thus sometimes
> it is not reasonable/necessary to fix).

Yeah, it's hard. :-/

>> problem is something that is likely to be seen in the wild it's totally
>> okay for me if you get regzbot involved. FWIWI, it remains to be seen if
>> that's a good idea in general (and is likely something I will bring up
>> for discussion on this years kernel summit), but let's just give it a
>> try. :-D
> 
> Thanks, we will stop this default behavior to send them directly regzbot. 

See above, as I said, it's fine for me if you just continue to get
regzbot involved for now and I'll get in contact if it becomes a problem
for me.

> [...]
> BTW: i want to consult that anyone (or CI) else send report to regzbot directly so far?
> 
> [1] https://lore.kernel.org/lkml/6b12a0b4-2f6d-1c35-f2e2-a28022583c47@leemhuis.info/

A few developers and users get regzbot directly involved when reporting
regressions, but I add most of the issues to the tracking. But no CI is
doing it currently. How to handle reports from CI is actually something
I hope to discuss on kernel and/or maintainers summit in ~10 days, if
time permits.

Ciao, Thorsten

Re: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Philip Li]

On Fri, Sep 02, 2022 at 01:23:55PM +0200, Thorsten Leemhuis wrote:
> TWIMC for those that might not be aware of it: there is a parallel
> discussion about the interaction about 0day and regzbot ongoing here:
> https://lore.kernel.org/regressions/57c596f7-014f-1833-3173-af3bad2ca45d@leemhuis.info/
> 
> On 01.09.22 15:53, Philip Li wrote:
> > On Mon, Aug 15, 2022 at 09:19:30PM +0800, Thorsten Leemhuis wrote:
> >> On 10.08.22 07:44, Si, Beibei wrote:
> > [...]
> >> Would be really really great if these mails could also directly tell
> >> users to add links tags that point to the report, e.g. in this case the
> >> mail from Oliver that started this thread:
> >>
> >> ```
> >>  If you fix the issue, kindly add following tag
> >>  Reported-by: kernel test robot <oliver.sang@intel.com>
> >>  Link: https://lore.kernel.org/lkml/YvEgyQM%2FWi0E2J3J@xsang-OptiPlex-9020/
> >> ```
> >>
> >> Obviously you need the msgid of the mail before you sent it in this
> >> case, but I assume you generate those mails semi-automatically anyway,
> >> so it hopefully won't be too hard to add this.
> > 
> > Thanks, this is really great suggestion for us, we will be able to add
> > this Link tag in future.
> 
> Great, thx.
> 
> > [...]
> >> I care deeply in the case of 0-bot when the reports contains lines like
> >> this:
> >>
> >>>> #regzbot introduced: efcfec579f
> >> That's because regzbot uses the URL in Link: tags to associate patch
> >> postings and commits with reports -- and even automatically closes
> >> regression tracking entries in case a fix linking to a tracked report is
> >> committed to the appropriate tree. A proper "Link:" tag thus saves me a
> >> lot of trouble, as I otherwise have to tell regzbot manually about each
> >> fix for tracked issues, which quickly becomes a PITA. :-/
> >>
> >> BTW: I noticed this was not the only recent reports from the kernel test
> >> robot that directly got regzbot involved, but not all do. Is some bot
> >> decising this or a human?
> > 
> > this is controlled by human, we try to connect with regzbot for the regression
> > we found on mainline. So we add #regzbot after we confirm the issue is valid
> > on mainline.
> 
> Okay, good to know. As maybe visible between the lines in the other mail
> I linked above already: I guess it's fine that way and we should
> continue with this and just see how it goes.

Got it, as replied in https://lore.kernel.org/regressions/57c596f7-014f-1833-3173-af3bad2ca45d@leemhuis.info/,
we will get ready for what you suggested, and send selected reports on mainline
to regzbot.

> 
> > BTW: 0day does testing on nearly all repos from developer to maintainers
> > to next and mainline, thus part of them are bisected down to mainline.
> 
> Yeah, I know. Regzbot in principle is handling next as well, but I guess
> we should ignore that for now with 0day, as keeping an eye on the
> reports against mainline keeps me quite busy already.

Got it, we will focus on mainline to track valuable ones.

> 
> >> Because the thing is: the time I can spend on tracking regressions is
> >> limited, hence I (at least for now) want to avoid spending any time on
> >> regressions that likely only ever show up in CI testing. But if the
> > 
> > got it, probably we need consider a few test suites (and kernel configruations)
> > that is more "standard", such as kselftests. But this is hard, for example,
> > we detects performance issue on micro benchmark, and it only shows one perspective
> > to developer as it may not reflect the use scenario of developer (thus sometimes
> > it is not reasonable/necessary to fix).
> 
> Yeah, it's hard. :-/
> 
> >> problem is something that is likely to be seen in the wild it's totally
> >> okay for me if you get regzbot involved. FWIWI, it remains to be seen if
> >> that's a good idea in general (and is likely something I will bring up
> >> for discussion on this years kernel summit), but let's just give it a
> >> try. :-D
> > 
> > Thanks, we will stop this default behavior to send them directly regzbot. 
> 
> See above, as I said, it's fine for me if you just continue to get
> regzbot involved for now and I'll get in contact if it becomes a problem
> for me.

Got it, thanks a lot

> 
> > [...]
> > BTW: i want to consult that anyone (or CI) else send report to regzbot directly so far?
> > 
> > [1] https://lore.kernel.org/lkml/6b12a0b4-2f6d-1c35-f2e2-a28022583c47@leemhuis.info/
> 
> A few developers and users get regzbot directly involved when reporting
> regressions, but I add most of the issues to the tracking. But no CI is
> doing it currently. How to handle reports from CI is actually something
> I hope to discuss on kernel and/or maintainers summit in ~10 days, if
> time permits.

We will be very glad to follow the decision if any is made there, and share
our thinking along the way to see how 0-day can be useful in this regression
tracking process.

> 
> Ciao, Thorsten

Re: [loop] efcfec579f: mdadm-selftests.12imsm-r0_2d-grow-r0_3d.fail #forregzbot

[Thorsten Leemhuis]

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

Hi, this is your Linux kernel regression tracker. Top-posting for once,
to make this easily accessible to everyone.

As per recent general discussions with the 0-day folks, I'm dropping
below regression report from the list of tracked issues, as this report
didn't gain any traction. That for example can happen (often without any
reply!) if the developers considered the regression of no practical
relevance, as they assume it only materializes in micro-benchmarks, is
due to a broken test case, or some fluke.

Not sure if that or something else is the reason why this particular
report didn't gain any traction, but I lack the bandwidth to follow-up
on each and every regression 0-day bot found and reported. At the
same time I don't want to keep these reports in the list of tracked
issues forever, as that creates noise and makes it harder to spot the
important issues in regzbot's reports and lists. That's why I hereby
remove it:

#regzbot invalid: 0-day report that didn't get traction; likely of no
relevance, not sure

Ciao, Thorsten

On 08.08.22 16:42, kernel test robot wrote:
> 
> (pleased be noted we found the issue still exists on latest maineline,
> so report though the commit is old, FYI)
> 
> 
> Greeting,
> 
> FYI, we noticed the following commit (built with gcc-11):
> 
> commit: efcfec579f6139528c9e6925eca2bc4a36da65c6 ("loop: fix no-unmap write-zeroes request behavior")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: mdadm-selftests
> version: mdadm-selftests-x86_64-5f41845-1_20220518
> with following parameters:
> 
> 	disk: 1HDD
> 	test_prefix: 12
> 	ucode: 0x28
> 
> 
> 
> on test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz 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 <oliver.sang@intel.com>
> 
> 2022-08-05 18:01:28 mkdir -p /var/tmp
> 2022-08-05 18:01:28 mke2fs -t ext3 -b 4096 -J size=4 -q /dev/sda1
> 2022-08-05 18:02:00 mount -t ext3 /dev/sda1 /var/tmp
> sed -e 's/{DEFAULT_METADATA}/1.2/g' \
> -e 's,{MAP_PATH},/run/mdadm/map,g'  mdadm.8.in > mdadm.8
> /usr/bin/install -D -m 644 mdadm.8 /usr/share/man/man8/mdadm.8
> /usr/bin/install -D -m 644 mdmon.8 /usr/share/man/man8/mdmon.8
> /usr/bin/install -D -m 644 md.4 /usr/share/man/man4/md.4
> /usr/bin/install -D -m 644 mdadm.conf.5 /usr/share/man/man5/mdadm.conf.5
> /usr/bin/install -D -m 644 udev-md-raid-creating.rules /lib/udev/rules.d/01-md-raid-creating.rules
> /usr/bin/install -D -m 644 udev-md-raid-arrays.rules /lib/udev/rules.d/63-md-raid-arrays.rules
> /usr/bin/install -D -m 644 udev-md-raid-assembly.rules /lib/udev/rules.d/64-md-raid-assembly.rules
> /usr/bin/install -D -m 644 udev-md-clustered-confirm-device.rules /lib/udev/rules.d/69-md-clustered-confirm-device.rules
> /usr/bin/install -D  -m 755 mdadm /sbin/mdadm
> /usr/bin/install -D  -m 755 mdmon /sbin/mdmon
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r0_2d-grow-r0_3d... 
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_3d! 
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_3d.log and /var/tmp/fail12imsm-r0_2d-grow-r0_3d.log for details
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r0_2d-grow-r0_4d... 
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_4d! 
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_4d.log and /var/tmp/fail12imsm-r0_2d-grow-r0_4d.log for details
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r0_2d-grow-r0_5d... 
> 	ERROR: dmesg prints errors when testing 12imsm-r0_2d-grow-r0_5d! 
> 
> FAILED - see /var/tmp/12imsm-r0_2d-grow-r0_5d.log and /var/tmp/fail12imsm-r0_2d-grow-r0_5d.log for details
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r0_3d-grow-r0_4d... 
> 	ERROR: dmesg prints errors when testing 12imsm-r0_3d-grow-r0_4d! 
> 
> FAILED - see /var/tmp/12imsm-r0_3d-grow-r0_4d.log and /var/tmp/fail12imsm-r0_3d-grow-r0_4d.log for details
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r5_3d-grow-r5_4d... succeeded
> Testing on linux-5.4.0-rc2-00010-gefcfec579f6139 kernel
> /lkp/benchmarks/mdadm-selftests/tests/12imsm-r5_3d-grow-r5_5d... succeeded
> 
> 
> 
> 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: efcfec579f
>