Hi Christophe Leroy and gpio experts,
Greeting!
Platform: Tigerlake-H and so on x86 platforms
All detailed info is in link: https://github.com/xupengfe/syzkaller_logs/tree/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5
Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5/bisect_info.txt
gpio-mockup.sh kslef-test failed in v6.3-rc5 kernel.
gpio-mockup.sh(gpio overflow test) in kself-test could reproduce this issue:
cd linux/tools/testing/selftests
1. ./kselftest_install.sh
2. cd linux/tools/testing/selftests/kselftest_install/gpio
# ./gpio-mockup.sh
1. Module load tests
1.1. dynamic allocation of gpio
2. Module load error tests
2.1 gpio overflow
test failed: unexpected chip - gpiochip1
GPIO gpio-mockup test FAIL
And the simplified steps to reproduce this issue are as follow:
"
# Load gpio_mockup with overflow ranges -1,1024:
modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
# Check is there some Call Trace generated in dmesg
dmesg | grep -C 5 Call
# Should not generate any gpiochip folder like /sys/kernel/debug/gpio-mockup/gpiochip1
# Because load gpio_mockup with overflow ranges -1,1024
find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
# Unload the gpio_mockup module
modprobe -r gpio_mockup
# Check is there "Call Trace" generated in dmesg
dmesg | grep -C 5 Call
"
Actually the judgement "gpio-mockup.sh" test/bisect judgement point is that:
Should not generate any gpiochip folder like
/sys/kernel/debug/gpio-mockup/gpiochip1 after load gpio_mockup with overflow
ranges -1,1024.
I met gpio-mockup.sh test failed but there is no any "Call Trace" dmesg info
sometimes.
So the shortest check steps are as follow:
"
1. modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
After above gpio_mockup module loaded with overflow range "-1,1024":
Correct behavior as previous v6.1 or older kernel:"gpio should not load "gpiochip1" due to overflow range -1,1024";
Wrong behavior in v6.3-rc5 kernel: "gpio *load* "gpiochip1" with overflow range -1,1024 and "gpiochip1" should not be loaded".
The underlying problem was already buried here.
2. Could use below command to check if "gpiochip1" generated:
As before v6.1, there was no "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder due to overflow range -1,1024";
Wrong behavior in v6.3-rc5 kernel: "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder generated as follow command check:
# find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
/sys/kernel/debug/gpio-mockup/gpiochip1
If there is gpiochip* generated, gpio-mockup.sh kself-test would be failed also.
"
Bisected and found the bad commit was:
"
7b61212f2a07a5afd213c8876e52b5c9946441e2
gpiolib: Get rid of ARCH_NR_GPIOS
"
And after reverted the above commit on top of v6.3-rc5 kernel, above
gpio-mockup.sh kself-test could pass and this issue was gone.
Now gpio-mockup.sh kself-test is failed on almost all x86 platform from
v6.2 cycle mainline kernel.
I hope above info is helpful to solve the "gpio-mockup.sh kself-test failed"
problem.
Thanks!
BR.
On Thu, Apr 6, 2023 at 12:15 PM Pengfei Xu <[email protected]> wrote:
>
> Hi Christophe Leroy and gpio experts,
>
> Greeting!
>
> Platform: Tigerlake-H and so on x86 platforms
>
> All detailed info is in link: https://github.com/xupengfe/syzkaller_logs/tree/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5
> Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5/bisect_info.txt
>
> gpio-mockup.sh kslef-test failed in v6.3-rc5 kernel.
> gpio-mockup.sh(gpio overflow test) in kself-test could reproduce this issue:
> cd linux/tools/testing/selftests
> 1. ./kselftest_install.sh
> 2. cd linux/tools/testing/selftests/kselftest_install/gpio
> # ./gpio-mockup.sh
> 1. Module load tests
> 1.1. dynamic allocation of gpio
> 2. Module load error tests
> 2.1 gpio overflow
> test failed: unexpected chip - gpiochip1
> GPIO gpio-mockup test FAIL
>
> And the simplified steps to reproduce this issue are as follow:
> "
> # Load gpio_mockup with overflow ranges -1,1024:
> modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
>
> # Check is there some Call Trace generated in dmesg
> dmesg | grep -C 5 Call
>
> # Should not generate any gpiochip folder like /sys/kernel/debug/gpio-mockup/gpiochip1
> # Because load gpio_mockup with overflow ranges -1,1024
> find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
>
> # Unload the gpio_mockup module
> modprobe -r gpio_mockup
> # Check is there "Call Trace" generated in dmesg
> dmesg | grep -C 5 Call
> "
>
> Actually the judgement "gpio-mockup.sh" test/bisect judgement point is that:
> Should not generate any gpiochip folder like
> /sys/kernel/debug/gpio-mockup/gpiochip1 after load gpio_mockup with overflow
> ranges -1,1024.
>
> I met gpio-mockup.sh test failed but there is no any "Call Trace" dmesg info
> sometimes.
>
> So the shortest check steps are as follow:
> "
> 1. modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
> After above gpio_mockup module loaded with overflow range "-1,1024":
> Correct behavior as previous v6.1 or older kernel:"gpio should not load "gpiochip1" due to overflow range -1,1024";
> Wrong behavior in v6.3-rc5 kernel: "gpio *load* "gpiochip1" with overflow range -1,1024 and "gpiochip1" should not be loaded".
> The underlying problem was already buried here.
>
> 2. Could use below command to check if "gpiochip1" generated:
> As before v6.1, there was no "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder due to overflow range -1,1024";
> Wrong behavior in v6.3-rc5 kernel: "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder generated as follow command check:
> # find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
> /sys/kernel/debug/gpio-mockup/gpiochip1
> If there is gpiochip* generated, gpio-mockup.sh kself-test would be failed also.
> "
>
> Bisected and found the bad commit was:
> "
> 7b61212f2a07a5afd213c8876e52b5c9946441e2
> gpiolib: Get rid of ARCH_NR_GPIOS
> "
> And after reverted the above commit on top of v6.3-rc5 kernel, above
> gpio-mockup.sh kself-test could pass and this issue was gone.
>
> Now gpio-mockup.sh kself-test is failed on almost all x86 platform from
> v6.2 cycle mainline kernel.
>
> I hope above info is helpful to solve the "gpio-mockup.sh kself-test failed"
> problem.
Thank you for the report and full analysis of the root cause. I think
we may fix the test script however the gpio-mockup is obsoleted and
should be actually replaced with tests again gpio-sim.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On 2023-04-06 at 13:26:36 +0300, Andy Shevchenko wrote:
> On Thu, Apr 6, 2023 at 12:15 PM Pengfei Xu <[email protected]> wrote:
> >
> > Hi Christophe Leroy and gpio experts,
> >
> > Greeting!
> >
> > Platform: Tigerlake-H and so on x86 platforms
> >
> > All detailed info is in link: https://github.com/xupengfe/syzkaller_logs/tree/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5
> > Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/issue_bisect/230406_gpio-mockup_kselftest_failed_bisect_v63rc5/bisect_info.txt
> >
> > gpio-mockup.sh kslef-test failed in v6.3-rc5 kernel.
> > gpio-mockup.sh(gpio overflow test) in kself-test could reproduce this issue:
> > cd linux/tools/testing/selftests
> > 1. ./kselftest_install.sh
> > 2. cd linux/tools/testing/selftests/kselftest_install/gpio
> > # ./gpio-mockup.sh
> > 1. Module load tests
> > 1.1. dynamic allocation of gpio
> > 2. Module load error tests
> > 2.1 gpio overflow
> > test failed: unexpected chip - gpiochip1
> > GPIO gpio-mockup test FAIL
> >
> > And the simplified steps to reproduce this issue are as follow:
> > "
> > # Load gpio_mockup with overflow ranges -1,1024:
> > modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
> >
> > # Check is there some Call Trace generated in dmesg
> > dmesg | grep -C 5 Call
> >
> > # Should not generate any gpiochip folder like /sys/kernel/debug/gpio-mockup/gpiochip1
> > # Because load gpio_mockup with overflow ranges -1,1024
> > find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
> >
> > # Unload the gpio_mockup module
> > modprobe -r gpio_mockup
> > # Check is there "Call Trace" generated in dmesg
> > dmesg | grep -C 5 Call
> > "
> >
> > Actually the judgement "gpio-mockup.sh" test/bisect judgement point is that:
> > Should not generate any gpiochip folder like
> > /sys/kernel/debug/gpio-mockup/gpiochip1 after load gpio_mockup with overflow
> > ranges -1,1024.
> >
> > I met gpio-mockup.sh test failed but there is no any "Call Trace" dmesg info
> > sometimes.
> >
> > So the shortest check steps are as follow:
> > "
> > 1. modprobe -q gpio_mockup gpio_mockup_ranges="-1,1024"
> > After above gpio_mockup module loaded with overflow range "-1,1024":
> > Correct behavior as previous v6.1 or older kernel:"gpio should not load "gpiochip1" due to overflow range -1,1024";
> > Wrong behavior in v6.3-rc5 kernel: "gpio *load* "gpiochip1" with overflow range -1,1024 and "gpiochip1" should not be loaded".
> > The underlying problem was already buried here.
> >
> > 2. Could use below command to check if "gpiochip1" generated:
> > As before v6.1, there was no "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder due to overflow range -1,1024";
> > Wrong behavior in v6.3-rc5 kernel: "/sys/kernel/debug/gpio-mockup/gpiochip1" sysfs folder generated as follow command check:
> > # find "/sys/kernel/debug/gpio-mockup/" -name gpiochip* -type d | sort
> > /sys/kernel/debug/gpio-mockup/gpiochip1
> > If there is gpiochip* generated, gpio-mockup.sh kself-test would be failed also.
> > "
> >
> > Bisected and found the bad commit was:
> > "
> > 7b61212f2a07a5afd213c8876e52b5c9946441e2
> > gpiolib: Get rid of ARCH_NR_GPIOS
> > "
> > And after reverted the above commit on top of v6.3-rc5 kernel, above
> > gpio-mockup.sh kself-test could pass and this issue was gone.
> >
> > Now gpio-mockup.sh kself-test is failed on almost all x86 platform from
> > v6.2 cycle mainline kernel.
> >
> > I hope above info is helpful to solve the "gpio-mockup.sh kself-test failed"
> > problem.
>
> Thank you for the report and full analysis of the root cause. I think
> we may fix the test script however the gpio-mockup is obsoleted and
> should be actually replaced with tests again gpio-sim.
>
Thanks for your info! So we should ignore the gpio-mockup module related
test next time and the gpio-mockup kself-test is not necessary.
My colleague "Lai Yi" also found this issue.
https://lore.kernel.org/lkml/[email protected]/
If there is a patch update please add:
"Reported-by: Pengfei Xu <[email protected]>
Reported-by: Yi Lai <[email protected]>
"
Thanks!
BR.
-Pengfei
> --
> With Best Regards,
> Andy Shevchenko