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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5770245.DvuYhMxLoT@kreacher>
Date: Thu, 21 Mar 2024 17:33:48 +0100
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Francisco Ayala Le Brun <francisco@...eowindow.eu>,
 Linus Walleij <linus.walleij@...aro.org>
Cc: Adrian Hunter <adrian.hunter@...el.com>, linux-mmc@...r.kernel.org,
 linux-kernel@...r.kernel.org, ulf.hansson@...aro.org,
 Linux ACPI <linux-acpi@...r.kernel.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Mario Limonciello <mario.limonciello@....com>,
 "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: Bug report: probe of AMDI0040:00 failed with error -16

On Wednesday, March 20, 2024 8:29:55 PM CET Rafael J. Wysocki wrote:
> On Tuesday, March 19, 2024 5:20:41 PM CET Adrian Hunter wrote:
> > On 19/03/24 16:43, Francisco Ayala Le Brun wrote:
> > > Hello,
> > > 
> > > I would like to report a bug.
> > > 
> > > Issue description:
> > > After updating a GHF51 SBC to a newer kernel version, the system was
> > 
> > What was the older / working kernel version?  Are you able
> > to git bisect?
> > 
> > > no longer able to boot. Running the "lsblk" command in the recovery
> > > console showed no mmc storage detected.
> > > 
> > > System Information:
> > > OS: Fedora 40 x86_64
> > > Kernel: 6.8.0-0.rc6.49.fc40.x86_64
> > > 
> > > Relevant Logs:
> > 
> > Really no error / fail messages before the stack dump?
> > 
> > > [   10.920756] Call Trace:
> > > [   10.920763]  <TASK>
> > > [   10.920771]  dump_stack_lvl+0x4d/0x70
> > > [   10.920786]  __setup_irq+0x530/0x6c0
> > > [   10.920801]  request_threaded_irq+0xe5/0x180
> > > [   10.920813]  ? __pfx_sdhci_thread_irq+0x10/0x10 [sdhci]
> > > [   10.920843]  __sdhci_add_host+0x108/0x360 [sdhci]
> > > [   10.920871]  sdhci_acpi_probe+0x3a8/0x500 [sdhci_acpi]
> > > [   10.920894]  platform_probe+0x44/0xa0
> > > [   10.920908]  really_probe+0x19e/0x3e0
> > > [   10.930244]  __driver_probe_device+0x78/0x160
> > > [   10.930264]  driver_probe_device+0x1f/0xa0
> > > [   10.930273]  __driver_attach_async_helper+0x5e/0xe0
> > > [   10.930284]  async_run_entry_fn+0x34/0x130
> > > [   10.930296]  process_one_work+0x170/0x330
> > > [   10.930309]  worker_thread+0x273/0x3c0
> > > [   10.934639]  ? __pfx_worker_thread+0x10/0x10
> > > [   10.934654]  kthread+0xe8/0x120
> > > [   10.934663]  ? __pfx_kthread+0x10/0x10
> > > [   10.934671]  ret_from_fork+0x34/0x50
> > > [   10.934681]  ? __pfx_kthread+0x10/0x10
> > > [   10.934688]  ret_from_fork_asm+0x1b/0x30
> > > [   10.934708]  </TASK>
> > > [   10.940978] mmc0: Failed to request IRQ 7: -16
> > > [   10.943885] sdhci-acpi: probe of AMDI0040:00 failed with error -16
> > 
> > 16 is EBUSY which seems to be used by __setup_irq() for
> > irq mismatch
> 
> Would you be able to test the patch below and see if it helps?
> 
> ---
>  drivers/pinctrl/pinctrl-amd.c |    2 +-
>  include/linux/interrupt.h     |    5 ++++-
>  kernel/irq/manage.c           |   13 +++++++++++--
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> Index: linux-pm/include/linux/interrupt.h
> ===================================================================
> --- linux-pm.orig/include/linux/interrupt.h
> +++ linux-pm/include/linux/interrupt.h
> @@ -67,6 +67,8 @@
>   *                later.
>   * IRQF_NO_DEBUG - Exclude from runnaway detection for IPI and similar handlers,
>   *		   depends on IRQF_PERCPU.
> + * IRQF_COND_ONESHOT - Agree to do IRQF_ONESHOT if already set for a shared
> + *                 interrupt.
>   */
>  #define IRQF_SHARED		0x00000080
>  #define IRQF_PROBE_SHARED	0x00000100
> @@ -82,6 +84,7 @@
>  #define IRQF_COND_SUSPEND	0x00040000
>  #define IRQF_NO_AUTOEN		0x00080000
>  #define IRQF_NO_DEBUG		0x00100000
> +#define IRQF_COND_ONESHOT	0x00200000
>  
>  #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND | IRQF_NO_THREAD)
>  

We actually can get away without defining a new IRQ flag, as in
the patch below.

It is not super-clean, but should do the work.

Linus, what do you think?

---
 drivers/pinctrl/pinctrl-amd.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/pinctrl/pinctrl-amd.c
===================================================================
--- linux-pm.orig/drivers/pinctrl/pinctrl-amd.c
+++ linux-pm/drivers/pinctrl/pinctrl-amd.c
@@ -1159,7 +1159,18 @@ static int amd_gpio_probe(struct platfor
 	}
 
 	ret = devm_request_irq(&pdev->dev, gpio_dev->irq, amd_gpio_irq_handler,
-			       IRQF_SHARED | IRQF_ONESHOT, KBUILD_MODNAME, gpio_dev);
+			       IRQF_SHARED | IRQF_PROBE_SHARED, KBUILD_MODNAME,
+			       gpio_dev);
+	/*
+	 * There can be a flags mismatch if IRQF_ONESHOT has been set for the
+	 * IRQ already, so if the error code indicates that, try again with
+	 * IRQF_ONESHOT set.
+	 */
+	if (ret == -EBUSY)
+		ret = devm_request_irq(&pdev->dev, gpio_dev->irq, amd_gpio_irq_handler,
+				       IRQF_SHARED | IRQF_ONESHOT, KBUILD_MODNAME,
+				       gpio_dev);
+
 	if (ret)
 		goto out2;
 




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ