On Thu, Apr 6, 2023 at 12:15 PM Pengfei Xu <pengfei.xu@xxxxxxxxx> 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
