[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <trinity-4f6dfbb9-adbe-4569-a1de-1e6502eea309-1632904717666@3c-app-gmx-bs21>
Date: Wed, 29 Sep 2021 10:38:37 +0200
From: Lino Sanfilippo <LinoSanfilippo@....de>
To: Mark Brown <broonie@...nel.org>
Cc: f.fainelli@...il.com, rjui@...adcom.com, sbranden@...adcom.com,
bcm-kernel-feedback-list@...adcom.com, nsaenz@...nel.org,
linux-spi@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
jgg@...pe.ca, p.rosenberger@...bus.com,
linux-integrity@...r.kernel.org, stable@...r.kernel.org
Subject: Aw: Re: [PATCH] spi: bcm2835: do not unregister controller in
shutdown handler
Hi,
> Gesendet: Dienstag, 28. September 2021 um 22:08 Uhr
> Von: "Mark Brown" <broonie@...nel.org>
> An: "Lino Sanfilippo" <LinoSanfilippo@....de>
> Cc: f.fainelli@...il.com, rjui@...adcom.com, sbranden@...adcom.com, bcm-kernel-feedback-list@...adcom.com, nsaenz@...nel.org, linux-spi@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, jgg@...pe.ca, p.rosenberger@...bus.com, linux-integrity@...r.kernel.org, stable@...r.kernel.org
> Betreff: Re: [PATCH] spi: bcm2835: do not unregister controller in shutdown handler
>
> On Tue, Sep 28, 2021 at 09:56:57PM +0200, Lino Sanfilippo wrote:
> > Do not unregister the SPI controller in the shutdown handler. The reason
> > to avoid this is that controller unregistration results in the slave
> > devices remove() handler being called which may be unexpected for slave
> > drivers at system shutdown.
> >
> > One example is if the BCM2835 driver is used together with the TPM SPI
> > driver:
> > At system shutdown first the TPM chip devices (pre) shutdown handler
> > (tpm_class_shutdown) is called, stopping the chip and setting an operations
> > pointer to NULL.
> > Then since the BCM2835 shutdown handler unregisters the SPI controller the
> > TPM SPI remove function (tpm_tis_spi_remove) is also called. In case of
> > TPM 2 this function accesses the now nullified operations pointer,
> > resulting in the following NULL pointer access:
> >
> > [ 174.078277] 8<--- cut here ---
> > [ 174.078288] Unable to handle kernel NULL pointer dereference at virtual address 00000034
> > [ 174.078293] pgd = 557a5fc9
> > [ 174.078300] [00000034] *pgd=031cf003, *pmd=00000000
> > [ 174.078317] Internal error: Oops: 206 [#1] SMP ARM
> > [ 174.078323] Modules linked in: tpm_tis_spi tpm_tis_core tpm spidev gpio_pca953x mcp320x rtc_pcf2127 industrialio regmap_i2c regmap_spi 8021q garp stp llc ftdi_sio6
>
> Please think hard before including complete backtraces in upstream
> reports, they are very large and contain almost no useful information
> relative to their size so often obscure the relevant content in your
> message. If part of the backtrace is usefully illustrative (it often is
> for search engines if nothing else) then it's usually better to pull out
> the relevant sections.
>
Thank you for the feedback, I will omit the stack trace in the next version.
Regards,
Lino
Powered by blists - more mailing lists