Re: [BUG] tpm: prolonged stall in vtpm_proxy_fops_release() on Linux 7.3

[Stefan Berger <stefanb@linux.ibm.com>]

On 11/1/26 12:36 PM, Jarkko Sakkinen wrote:
> On Sun, Nov 01, 2026 at 09:22:30AM +0800, 铮 wrote:
>> Hi Peter, Jarkko and Jason,
> 
> Adding Stefan.
> 
>>
>> I observed a task hang in vtpm_proxy_fops_release() while fuzzing the
>> vTPM proxy with syzkaller. I reproduced it on Linux 7.3.0: the campaign
>> observed the hang 4 times; replaying the stored sequence reproduced it
>> once in an automated replay and three times in manual replays. In every
>> case a process is blocked for 143+ seconds in
>> vtpm_proxy_fops_release() -> vtpm_proxy_work_stop() -> flush_work(),
>> while at the same time the sysrq-t dumps show a chip-register work
>> (vtpm_proxy_work -> tpm_chip_register() -> tpm_chip_start() ->
>> vtpm_proxy_request_locality()) running on the tpm-vtpm workqueue plus a
>> backlog of further queued chip-register works. Which queued work the
>> blocked release is waiting for is unconfirmed. All logs end while the
>> task is still blocked, so I cannot say how long the stall ultimately
>> lasts; I am not claiming a permanent deadlock.
>>
>> Environment
>> -----------
>> - Kernel: 7.3.0-kernsight-kasan #1 SMP PREEMPT_DYNAMIC, built 2026-10-20,
>>    x86_64. Vanilla 7.3.0 source tarball (sha256
>>    87363c24f10e06321eb362765521094e94471f6bff8bce2d6b3e40f39f004953),
>>    built with KASAN/KCOV. No TPM changes were made for this testing
>>    (drivers/char/tpm/ matches vanilla apart from build artifacts).
>> - Guest: QEMU/KVM, 4 vCPU, 6 GiB, 8 scratch virtio disks, 2 NVDIMM/pmem
>>    devices, 2 NUMA nodes (the syzkaller standard environment). A fresh VM
>>    was used for every reproduction run.
>> - Syzkaller: revision 853b104bb454141a5b0fc0e4218ec78e9f34ffb1+
>>    (2026-09-18). The "+" denotes local KernSight integration changes
>>    (seed ordering/state feedback: pkg/kernsight, prog/kernsight_*,
>>    syz-manager/kernsight_*, pkg/execbackend, snapshot support in vm/qemu).
>>    They do not change the TPM syscall descriptions or the executor
>>    semantics.
>> - Reproduction: the campaign observed the hang 4 times; replaying the
>>    stored programs reproduced it once in an automated replay, three
>>    times as a single 50-program sequence, and once with the two-step
>>    form above (one of the manual replays is captured only as a sysrq-t
>>    dump). Four runs on a bare fresh VM with a *different kernel command

Four runs out of four?

>>    line* and without the scratch/pmem/NUMA layout recorded no hang --

Does this mean that the 'scratch/pemem/NUMA layout' is required to 
reproduce the hang?

>>    since the command line differs as well, these runs cannot attribute
>>    the effect to the device layout.

What is 'device layout'?