Re: Recent tpm_tis IRQ handling changes are causing kernel backtraces

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 5/31/21 6:36 AM, Jarkko Sakkinen wrote:
> On Thu, May 27, 2021 at 05:27:49PM +0200, Hans de Goede wrote:
>> This is from:
>> https://retrace.fedoraproject.org/faf/reports/74723/  (public)
> 
> I wonder if this occurs only with O_NONBLOCK.
> 
> Any chances to get the output of
> 
>   sudo tools/testing/selftests/tpm2/test_smoke.sh
> 
> ?
> 
> It's obvious that there is some sort of bug, but it's not yet obvious that
> this bug is connected to the locality issue yet, as in this case locality
> is successfully reserved by tpm_try_get_ops() in tpm_dev_async_work()
> (driver/chars/tpm/tpm-dev-common.c).

As mentioned I've asked the user to try with tpm_tis.interrupts=0 and see
if that makes a difference. I got a reply that the user only hit this
once and that this is not (easily) reproducible :|

"looks like a spurious problem that may already be solved."

I did get permission to open up the bug (make it public) so if you want
more info it is probably easiest if you interact directly with the
reporter here:

https://bugzilla.redhat.com/show_bug.cgi?id=1964974

If you don't already have a bugzilla.redhat.com account, creating one
is super easy, you only need to enter your email address and pick a
password.


>> The second backtrace is from:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1964735  (private)
>> https://retrace.fedoraproject.org/faf/reports/38209/ (public)
> 
> This must have a successful tpm_try_get_ops() for ima_tpm_chip
> (map_tpm_chip == tpm_default_chip()).
> 
> Would also be interesting to see the status code, i.e. TPM_STS_0
> register value, but these are completely lacking the warning
> message, and the warning message apparently does not have the
> information printed.
> 
> I'll send a patch that updates the warning, and also retract
> of using WARN() given panic-on-warn is commonly set [*]. It's
> not right thing to do to torn down the machine because of invalid
> status code.
> 
> So, I'll fix that by instead:
> 
>   dev_err_once(&chip->dev, "invalid status: 0x%02x\n", status);
>   dump_stack();
> 
> Should be visible enough to get notified, and provides the important
> stack dump to quickly find possible impairment of tpm_try_get_ops(),
> and also contains the missing status code printout.

Sounds good, thanks.

>> Note there is public bugzilla, with dmesg with the same backtrace
>> (on the same laptop), but then with 5.12.5 here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1963712
>>
>> There are also 2 interesting comments on the public bugzilla:
>>
>> "updated to linux kernel 5.12.5 performed 
>> sudo shutdown -r now"
>>
>> "I installed Fedora 34 UEFI from USB on a Dell XPS 13 Developer Edition"
>>
>> So it seems this is happening on the "Dell XPS 13 Developer
>> Edition".
>>
>> I've also checked the BIOS versions involved in the 2 different
>> bugs and 1964735 has "BIOS 1.2.5 12/10/2020" where as
>> 1963712 has "BIOS 2.2.0 04/06/2021" so this seems to be
>> independent of the BIOS version.
>>
>> ###
>>
>> Interestingly enough the first backtrace is also happening on a:
>> "Dell Inc. XPS 13 9310/0MRT12, BIOS 2.2.0 04/06/2021"
>>
>> So it seems that at least with 5.12.6 (which has the last 2 fixes)
>> all reports are about the XPS 13 9310. I wonder if there is an
>> issue with the TPM interrupt line on the XPS 13 9310; I've asked the
>> reporters to try adding tpm_tis.interrupts=0 to their kernel commandline.
> 
> This is helpful for sure that these all are happening on matching hardware.

Ack, I'm still waiting to hear back from reporters of the second
backtrace, wrt tpm_tis.interrupts=0.

I've marked a couple of reports of the second backtrace as duplicates of:
https://bugzilla.redhat.com/show_bug.cgi?id=1963712

So all reporters of this are now following this public bug, so if you want
to reach out to them with questions that is probably the easiest way.

Regards,

Hans