From: Sean Christopherson <seanjc@google.com>
To: Ackerley Tng <ackerleytng@google.com>
Cc: Fuad Tabba <tabba@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oupton@kernel.org>, Will Deacon <will@kernel.org>,
David Matlack <dmatlack@google.com>,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: selftests: Fix FD double-close in kvm_vm_release()
Date: Wed, 13 May 2026 05:48:41 -0700 [thread overview]
Message-ID: <agRzKWDH4lpN1rJv@google.com> (raw)
In-Reply-To: <CAEvNRgHfBqqC1K7enCPX3jqWE0smJ3E0NE=kUPSX7N7g5KQrvg@mail.gmail.com>
On Tue, May 12, 2026, Ackerley Tng wrote:
> Fuad Tabba <tabba@google.com> writes:
> > kvm_vm_release() closes vmp->fd and vmp->kvm_fd unconditionally, and
> > kvm_vm_free() calls kvm_vm_release() at teardown. A test that calls
> > kvm_vm_release() and then kvm_vm_free() without a
> > vm_recreate_with_one_vcpu() in between double-closes both FDs. Since
> > kvm_close() asserts on close() failure, the second close trips
> > TEST_ASSERT and aborts the test, or, if the FD was recycled, silently
> > closes an unrelated file.
> >
>
> Never thought about this fd-recycling case, I think this change still
> has value in avoiding the silent closing of some other file.
I have no objection to invalidating the fds, I just don't want to make
kvm_vm_release() and kvm_vm_free() idempotent. The caller needs to not mess up.
prev parent reply other threads:[~2026-05-13 12:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 11:37 [PATCH 0/2] KVM: selftests: Fixes for guest_memfd_test and FD double-close Fuad Tabba
2026-05-11 11:37 ` [PATCH 1/2] KVM: selftests: Fix MADV_COLLAPSE build failure on older toolchains Fuad Tabba
2026-05-11 14:59 ` Sean Christopherson
2026-05-11 11:37 ` [PATCH 2/2] KVM: selftests: Fix FD double-close in kvm_vm_release() Fuad Tabba
2026-05-11 14:58 ` Sean Christopherson
2026-05-11 15:19 ` Fuad Tabba
2026-05-11 20:25 ` Sean Christopherson
2026-05-12 8:06 ` Fuad Tabba
2026-05-12 13:30 ` Sean Christopherson
2026-05-12 15:04 ` Will Deacon
2026-05-12 15:06 ` Fuad Tabba
2026-05-12 20:24 ` Ackerley Tng
2026-05-13 12:48 ` Sean Christopherson [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=agRzKWDH4lpN1rJv@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=tabba@google.com \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.