linux-kernel - Re: [PATCH] tpm,tpm_tis: Avoid warning splat at shutdown

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]

Date: Fri, 2 Feb 2024 02:13:32 +0100
From: Lino Sanfilippo <l.sanfilippo@...bus.com>
To: "Elliott, Robert (Servers)" <elliott@....com>,
 "jarkko@...nel.org" <jarkko@...nel.org>,
 "peterhuewe@....de" <peterhuewe@....de>
Cc: "LinoSanfilippo@....de" <LinoSanfilippo@....de>,
 "p.rosenberger@...bus.com" <p.rosenberger@...bus.com>,
 "lukas@...ner.de" <lukas@...ner.de>, "jgg@...pe.ca" <jgg@...pe.ca>,
 "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] tpm,tpm_tis: Avoid warning splat at shutdown


On 01.02.24 17:40, Elliott, Robert (Servers) wrote:
> ATTENTION: This e-mail is from an external sender. Please check attachments and links before opening e.g. with mouseover.
> 
> 
>> From: Lino Sanfilippo <l.sanfilippo@...bus.com>
>> Sent: Thursday, February 1, 2024 5:37 AM
>> Subject: [PATCH] tpm,tpm_tis: Avoid warning splat at shutdown
>>
>> If interrupts are not activated the work struct 'free_irq_work' is not
>> initialized. This results in a warning splat at module shutdown.
>>
>> Fix this by always initializing the work regardless of whether interrupts
>> are activated or not.
> 
> That's using flush_work(), which just waits for one to complete. Is there
> any case where multiple work entries could be queued, and cancel_work_sync()
> would be necessary?
> 

No. There is only one work struct (namely free_irq_work) and it can only be
queued once at a time (note that schedule_work() does not queue the same work
again if it is already queued).   

> tpm_tis_probe_irq() has a loop calling tpm_tis_probe_irq_single()
> for 3 to 15. Could each of those could trigger an interrupt storm and
> call tpm_tis_revert_interrupts(), which calls schedule_work()?
> 
> 

The iteration stops as soon as there is an interrupt found that "works" (i.e.
as soon as one interrupt fires, see the "irq test" in tpm_tis_send()). If this
irq starts a storm it is handled by the implemented irq storm handling and
deactivated. No other interrupts are activated afterwards. So no,
I do not see that multiple interrupt storms are possible at the same time.

Regards,
Lino