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

[Stefan Berger]

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'?