linux-kernel - async probe: boot crash with v5.10.188 on STM32MP157

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <556007adcfd12f5f0bd997dba6c050aa28922ed3.camel@foss.st.com>
Date:   Mon, 18 Sep 2023 14:26:21 +0200
From:   Antonio Borneo <antonio.borneo@...s.st.com>
To:     Saravana Kannan <saravanak@...gle.com>
CC:     Linus Walleij <linus.walleij@...aro.org>,
        <linux-kernel@...r.kernel.org>,
        Alexandre TORGUE <alexandre.torgue@...s.st.com>
Subject: async probe: boot crash with v5.10.188 on STM32MP157

Hi Saravana,

while devlink and async probe looks ok in v6.6-rc1, I get randomly boot
crash on STM32MP157 with kernel v5.10.188 after the upstream commit
3108eb2e8aa7 ("mmc: mmci: Set PROBE_PREFER_ASYNCHRONOUS") got backported.

In v6.6-rc1, really_probe() checks for probe dependencies with
device_links_check_suppliers(). In older kernels this part is missing.
In the specific case of STM32MP157, the driver mmci can get async-probed
while the probe of pinctrl/stm32/pinctrl-stm32.c has already registered
the pinctrl but has not added any gpiochip yet.
This causes pinmux_ops::set_mux() to fail and thus mmci probe fails too.

Boot log contains:

[2.205476] stm32mp157-pinctrl soc:pin-controller@...02000: No gpio range defined.
[2.205515] mmci-pl18x 58005000.sdmmc: Error applying setting, reverse things back
[2.205828] mmci-pl18x: probe of 58005000.sdmmc failed with error -22
[2.210434] stm32mp157-pinctrl soc:pin-controller@...02000: GPIOA bank added

>From a quick code check, also the LTS v5.15 and v6.1 looks impacted, but
I have not tested them, so far, due to the difficulties to replicate the
crash.

Is there any mandatory upstream patch that got lost in the backport process?

Or is there something incorrect to be fixed in pinctrl-stm32 driver?

What are the possible workaround I can use? Would kernel flag fw_devlink=off
work reliably for all the mentioned kernel versions?

Regards,
Antonio