netdev - Re: [PATCH net-next 04/12] selftests/vsock: avoid multi-VM pidfile collisions with QEMU

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]

Message-ID: <aP+zZMtf7FwwmqVF@devvm11784.nha0.facebook.com>
Date: Mon, 27 Oct 2025 11:01:08 -0700
From: Bobby Eshleman <bobbyeshleman@...il.com>
To: Simon Horman <horms@...nel.org>
Cc: Stefano Garzarella <sgarzare@...hat.com>, Shuah Khan <shuah@...nel.org>,
	Jakub Kicinski <kuba@...nel.org>, virtualization@...ts.linux.dev,
	netdev@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bobby Eshleman <bobbyeshleman@...a.com>
Subject: Re: [PATCH net-next 04/12] selftests/vsock: avoid multi-VM pidfile
 collisions with QEMU

On Mon, Oct 27, 2025 at 04:57:29PM +0000, Simon Horman wrote:
> On Wed, Oct 22, 2025 at 06:00:08PM -0700, Bobby Eshleman wrote:
> > From: Bobby Eshleman <bobbyeshleman@...a.com>
> > 
> > Change QEMU to use generated pidfile names instead of just a single
> > globally-defined pidfile. This allows multiple QEMU instances to
> > co-exist with different pidfiles. This is required for future tests that
> > use multiple VMs to check for CID collissions.
> > 
> > Additionally, this also places the burden of killing the QEMU process
> > and cleaning up the pidfile on the caller of vm_start(). To help with
> > this, a function terminate_pidfiles() is introduced that callers use to
> > perform the cleanup. The terminate_pidfiles() function supports multiple
> > pidfile removals because future patches will need to process two
> > pidfiles at a time.
> 
> It seems that this will no longer cleanup, via a trap, if
> there is an early exit. Is that intentional?
> 

Yes, intentional. We're trusting the vm_start() caller to do any cleanup
now. The assumption being that with no "set -e", vm_start() should be
able to return to the caller.

If that seems too bold, we could add some function like create_pidfile()
that generates the pidfiles and registers them into an array that is
cleaned up via trap.

> This patch also changes the handling of QEMU_OPTS. I think
> that should be mentioned in the commit message too.
> 

Sounds good.

Best,
Bobby