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: <YmkFvmE+2CD3Bjs+@atomide.com>
Date:   Wed, 27 Apr 2022 11:58:38 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Discussions about the Letux Kernel <letux-kernel@...nphoenux.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: kernel panic with v5.18-rc1 on OpenPandora (only)

* Tony Lindgren <tony@...mide.com> [220427 08:40]:
> Hi,
> 
> * H. Nikolaus Schaller <hns@...delico.com> [220426 20:16]:
> > Hi Tony,
> > I ran across a new issue on the OpenPandora (omap3530) first appearing with v5.18-rc1.
> > It seems as if there is something happening within the omap3 L3 irq handler which
> > is used (only?) for the wl1251. And this triggers the timeout BUG_ON() in
> > omap3_l3_app_irq().
> > 
> > I have not seen this issue on the GTA04.
> > 
> > It goes away if I remove the wlan interrupt from omap3-pandora-common.dtsi.
> > Interestingly, removing the wl1251.ko does NOT stop it. So it is not the driver.
> > 
> > git bisect reported:
> > 
> > a1c510d0adc604bb143c86052bc5be48cbcfa17c is the first bad commit
> > commit a1c510d0adc604bb143c86052bc5be48cbcfa17c
> > Author: Ard Biesheuvel <ardb@...nel.org>
> > Date:   Thu Sep 23 09:15:53 2021 +0200
> > 
> >     ARM: implement support for vmap'ed stacks
> >     
> > Any ideas?
> 
> We had to add commit 8cf8df89678a ("ARM: OMAP2+: Fix regression for smc
> calls for vmap stack") to fix vmap related issues in case you have not
> seen that one yet. This seems different though, it's like the L3 interrupt
> handler is not reading the right register?
> 
> Not sure why the L3 interrupt is triggering, that could be caused by
> another issue with the wl1251 somewhere.

Can you maybe try to temporarily disable the L3 driver and see if the stack
trace is more accurate on what goes wrong? Just comment out the line for
postcore_initcall_sync(omap3_l3_init) in drivers/bus/omap_l3_smx.c. The
system will hang on the invalid access rather than triggering the L3
error first.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ