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 pengfei.xu@intel.com 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_gpi... Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/issue_bisect/230406_gpi...

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/ZCvusEIauvO8BLM5@xpf.sh.intel.com/

If there is a patch update please add: "Reported-by: Pengfei Xu pengfei.xu@intel.com Reported-by: Yi Lai yi1.lai@intel.com "

Thanks! BR. -Pengfei

-- With Best Regards, Andy Shevchenko