From: Stefan Berger <stefanb@linux.ibm.com>
To: "Jarkko Sakkinen" <jarkko@kernel.org>, 铮 <fengaojigui88@gmail.com>
Cc: peterhuewe@gmx.de, Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity@vger.kernel.org, syzkaller@googlegroups.com,
linux-kernel@vger.kernel.org
Subject: Re: [BUG] tpm: prolonged stall in vtpm_proxy_fops_release() on Linux 7.3
Date: Fri, 6 Nov 2026 14:11:34 -0500 [thread overview]
Message-ID: <012799b9-aa35-4990-86df-23b012ab94e6@linux.ibm.com> (raw)
In-Reply-To: <aud4isATIt0JOOL_@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3857 bytes --]
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,
> >>
>> Question
>> --------
>> vtpm_proxy_tpm_req_canceled() already exists and the driver marks the
>> device as being torn down before flush_work(); from the captured dumps
>> I cannot tell why the wait nevertheless persists for minutes. Should
>> the release path be bounded, or should the in-flight chip-register work
>> be ended more promptly once the proxy is being torn down? I am happy to
>> test proposed patches.
I have tried to reproduce this now but cannot. The kernel fails for me
like this when booting with the suggested QEMU command line:
[ 3.224399][ T1] Timer migration: 2 hierarchy levels; 8 children
per group; 1 crossnode level
[ 3.239948][ T1] smp: Bringing up secondary CPUs ...
[ 3.243980][ T1] smpboot: x86: Booting SMP configuration:
[ 3.246035][ T1] .... node #0, CPUs: #1
[ 3.252255][ T1] .... node #1, CPUs: #2 #3
[ 0.076393][ T0] ------------[ cut here ]------------
[ 0.076393][ T0] sched: CPU #2's llc-sibling CPU #0 is not on the
same node! [node: 1 != 0]. Ignoring dependency.
[ 0.076393][ T0] WARNING: arch/x86/kernel/smpboot.c:329 at
topology_sane.isra.0+0x97/0xb0, CPU#2: swapper/2/0
[ 0.076393][ T0] Modules linked in:
[ 0.076393][ T0] CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted
7.3.0-kernsight-kasan #1 PREEMPT(full)
[ 0.076393][ T0] Hardware name: QEMU Ubuntu 26.04 PC (i440FX +
PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
[ 0.076393][ T0] RIP: 0010:topology_sane.isra.0+0xa3/0xb0
[ 0.076393][ T0] Code: 07 00 44 89 ef e8 ed fa 07 00 44 89 e7 89
c3 e8 e3 fa 07 00 41 89 c0 48 8d 3d 79 4e 3e 10 41 89 d9 44 89 e9 4c 89
fa 44 89 e6 <67> 48 0f b9 3a eb a5 66 0f 1f 44 00 00 90 90 90 90 90 90
90 90 90
[ 0.076393][ T0] RSP: 0000:ffffc900001afde0 EFLAGS: 00010092
The first thing I was going to try is whether this has something to do
with the 'STATE_OPENED_FLAG' flag. There's one location where this is
set and that's after the anon_inode_getfile() was called. For a server
side device to be able to access the device, udev would have to run.
Maybe udev does run between anon_inode_getfile() and the server side
opens the device and the immediately closes it and resets the flag
BEFORE current vtpm_proxy_fops_open() sets the flag and makes the client
think that there still is an server-side app responding to requests. So,
let's reverse the order and set the flag before the inode gets created
and the flag can be reset - patch also as attachment:
diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
b/drivers/char/tpm/tpm_vtpm_proxy.c
index b81fd2a537df..245a8f959bc7 100644
--- a/drivers/char/tpm/tpm_vtpm_proxy.c
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c
@@ -197,10 +197,8 @@ static __poll_t vtpm_proxy_fops_poll(struct file
*filp, poll_table *wait)
*
* Called when setting up the anonymous file descriptor
*/
-static void vtpm_proxy_fops_open(struct file *filp)
+static void vtpm_proxy_fops_open(struct proxy_dev *proxy_dev)
{
- struct proxy_dev *proxy_dev = filp->private_data;
-
proxy_dev->state |= STATE_OPENED_FLAG;
}
@@ -550,6 +548,9 @@ static struct file *vtpm_proxy_create_device(
goto err_delete_proxy_dev;
}
+ /* simulate an open() on the server side */
+ vtpm_proxy_fops_open(proxy_dev);
+
file = anon_inode_getfile("[vtpms]", &vtpm_proxy_fops, proxy_dev,
O_RDWR);
if (IS_ERR(file)) {
@@ -558,8 +559,6 @@ static struct file *vtpm_proxy_create_device(
}
/* from now on we can unwind with put_unused_fd() + fput() */
- /* simulate an open() on the server side */
- vtpm_proxy_fops_open(file);
if (proxy_dev->flags & VTPM_PROXY_FLAG_TPM2)
proxy_dev->chip->flags |= TPM_CHIP_FLAG_TPM2;
[-- Attachment #2: 0001-tpm-tpm_vtpm_proxy-Set-STATE_OPENED_FLAG-before-inod.patch --]
[-- Type: text/x-patch, Size: 2180 bytes --]
From d6c27b005dfca356fa33530696e21251d91421b7 Mon Sep 17 00:00:00 2001
From: Stefan Berger <stefanb@linux.ibm.com>
Date: Fri, 6 Nov 2026 12:43:56 -0600
Subject: [PATCH] tpm: tpm_vtpm_proxy: Set STATE_OPENED_FLAG before inode is
created
The server-side inode is currently created before the STATE_OPENED_FLAG
is set. Theoretically, an application could open the server side file
after anon_inode_getfile() ran in the driver (and udev created the
device) and then immediately close the file descriptor and clear the still
unset STATE_OPENED_FLAG that currently gets set after
anon_inode_getfile(). Therefore, reverse the order so that the flag
never gets set after it was attempted to be cleared.
If the flag is set while no server-side application responds to requests,
the client-side may wait for a response until timeout.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
drivers/char/tpm/tpm_vtpm_proxy.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
index b81fd2a537df..245a8f959bc7 100644
--- a/drivers/char/tpm/tpm_vtpm_proxy.c
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c
@@ -197,10 +197,8 @@ static __poll_t vtpm_proxy_fops_poll(struct file *filp, poll_table *wait)
*
* Called when setting up the anonymous file descriptor
*/
-static void vtpm_proxy_fops_open(struct file *filp)
+static void vtpm_proxy_fops_open(struct proxy_dev *proxy_dev)
{
- struct proxy_dev *proxy_dev = filp->private_data;
-
proxy_dev->state |= STATE_OPENED_FLAG;
}
@@ -550,6 +548,9 @@ static struct file *vtpm_proxy_create_device(
goto err_delete_proxy_dev;
}
+ /* simulate an open() on the server side */
+ vtpm_proxy_fops_open(proxy_dev);
+
file = anon_inode_getfile("[vtpms]", &vtpm_proxy_fops, proxy_dev,
O_RDWR);
if (IS_ERR(file)) {
@@ -558,8 +559,6 @@ static struct file *vtpm_proxy_create_device(
}
/* from now on we can unwind with put_unused_fd() + fput() */
- /* simulate an open() on the server side */
- vtpm_proxy_fops_open(file);
if (proxy_dev->flags & VTPM_PROXY_FLAG_TPM2)
proxy_dev->chip->flags |= TPM_CHIP_FLAG_TPM2;
--
2.56.0
prev parent reply other threads:[~2026-11-06 19:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 1:22 铮
2026-11-01 17:36 ` Jarkko Sakkinen
2026-11-02 14:02 ` Stefan Berger
2026-11-02 17:37 ` 铮
2026-11-06 19:11 ` Stefan Berger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=012799b9-aa35-4990-86df-23b012ab94e6@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=fengaojigui88@gmail.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®