From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oupton@google.com>
Cc: pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu,
kvm@vger.kernel.org, maz@kernel.org
Subject: Re: [PATCH v2 4/5] KVM: Actually create debugfs in kvm_create_vm()
Date: Thu, 16 Jun 2022 18:03:23 +0000 [thread overview]
Message-ID: <Yqtwa03IWVNP4LLA@google.com> (raw)
In-Reply-To: <20220518175811.2758661-5-oupton@google.com>
On Wed, May 18, 2022, Oliver Upton wrote:
> Doing debugfs creation after vm creation leaves things in a
> quasi-initialized state for a while. This is further complicated by the
> fact that we tear down debugfs from kvm_destroy_vm(). Align debugfs and
> stats init/destroy with the vm init/destroy pattern to avoid any
> headaches. Pass around the fd number as a string, as poking at the fd in
> any other way is nonsensical.
"any other way before it is installed", otherwise it sounds like the fd is this
magic black box that KVM can't touch.
And the changes to pass @fdname instead of @fd should be a separate patch, both to
reduce churn and because it's not a risk free change, e.g. if this is the improper
size then bisection should point at the fdname patch, not at this combined patch.
char fdname[ITOA_MAX_LEN + 1];
> Note the fix for a benign mistake in error handling for calls to
> kvm_arch_create_vm_debugfs() rolled in. Since all implementations of
> the function return 0 unconditionally it isn't actually a bug at
> the moment.
>
> Lastly, tear down debugfs/stats data in the kvm_create_vm_debugfs()
> error path. Previously it was safe to assume that kvm_destroy_vm() would
> take out the garbage, that is no longer the case.
>
> Signed-off-by: Oliver Upton <oupton@google.com>
> ---
...
> @@ -4774,6 +4781,7 @@ EXPORT_SYMBOL_GPL(file_is_kvm);
>
> static int kvm_dev_ioctl_create_vm(unsigned long type)
> {
> + char fdname[ITOA_MAX_LEN + 1];
> int r, fd;
> struct kvm *kvm;
> struct file *file;
> @@ -4782,7 +4790,8 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> if (fd < 0)
> return fd;
>
> - kvm = kvm_create_vm(type);
> + snprintf(fdname, sizeof(fdname), "%d", fd);
Nit, I'd prefer a blank line here so that it's easier to see the call to
kvm_create_vm().
> + kvm = kvm_create_vm(type, fdname);
> if (IS_ERR(kvm)) {
> r = PTR_ERR(kvm);
> goto put_fd;
> @@ -4799,17 +4808,6 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> goto put_kvm;
> }
>
> - /*
> - * Don't call kvm_put_kvm anymore at this point; file->f_op is
> - * already set, with ->release() being kvm_vm_release(). In error
> - * cases it will be called by the final fput(file) and will take
> - * care of doing kvm_put_kvm(kvm).
> - */
I think we should keep the comment to warn future developers. I'm tempted to say
it could be reworded to say something like "if you're adding a call that can fail
at this point, you're doing it wrong". But for this patch, I'd say just leave the
comment intact.
> - if (kvm_create_vm_debugfs(kvm, r) < 0) {
> - fput(file);
> - r = -ENOMEM;
> - goto put_fd;
> - }
> kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
>
> fd_install(fd, file);
> --
> 2.36.1.124.g0e6072fb45-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, maz@kernel.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 4/5] KVM: Actually create debugfs in kvm_create_vm()
Date: Thu, 16 Jun 2022 18:03:23 +0000 [thread overview]
Message-ID: <Yqtwa03IWVNP4LLA@google.com> (raw)
In-Reply-To: <20220518175811.2758661-5-oupton@google.com>
On Wed, May 18, 2022, Oliver Upton wrote:
> Doing debugfs creation after vm creation leaves things in a
> quasi-initialized state for a while. This is further complicated by the
> fact that we tear down debugfs from kvm_destroy_vm(). Align debugfs and
> stats init/destroy with the vm init/destroy pattern to avoid any
> headaches. Pass around the fd number as a string, as poking at the fd in
> any other way is nonsensical.
"any other way before it is installed", otherwise it sounds like the fd is this
magic black box that KVM can't touch.
And the changes to pass @fdname instead of @fd should be a separate patch, both to
reduce churn and because it's not a risk free change, e.g. if this is the improper
size then bisection should point at the fdname patch, not at this combined patch.
char fdname[ITOA_MAX_LEN + 1];
> Note the fix for a benign mistake in error handling for calls to
> kvm_arch_create_vm_debugfs() rolled in. Since all implementations of
> the function return 0 unconditionally it isn't actually a bug at
> the moment.
>
> Lastly, tear down debugfs/stats data in the kvm_create_vm_debugfs()
> error path. Previously it was safe to assume that kvm_destroy_vm() would
> take out the garbage, that is no longer the case.
>
> Signed-off-by: Oliver Upton <oupton@google.com>
> ---
...
> @@ -4774,6 +4781,7 @@ EXPORT_SYMBOL_GPL(file_is_kvm);
>
> static int kvm_dev_ioctl_create_vm(unsigned long type)
> {
> + char fdname[ITOA_MAX_LEN + 1];
> int r, fd;
> struct kvm *kvm;
> struct file *file;
> @@ -4782,7 +4790,8 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> if (fd < 0)
> return fd;
>
> - kvm = kvm_create_vm(type);
> + snprintf(fdname, sizeof(fdname), "%d", fd);
Nit, I'd prefer a blank line here so that it's easier to see the call to
kvm_create_vm().
> + kvm = kvm_create_vm(type, fdname);
> if (IS_ERR(kvm)) {
> r = PTR_ERR(kvm);
> goto put_fd;
> @@ -4799,17 +4808,6 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> goto put_kvm;
> }
>
> - /*
> - * Don't call kvm_put_kvm anymore at this point; file->f_op is
> - * already set, with ->release() being kvm_vm_release(). In error
> - * cases it will be called by the final fput(file) and will take
> - * care of doing kvm_put_kvm(kvm).
> - */
I think we should keep the comment to warn future developers. I'm tempted to say
it could be reworded to say something like "if you're adding a call that can fail
at this point, you're doing it wrong". But for this patch, I'd say just leave the
comment intact.
> - if (kvm_create_vm_debugfs(kvm, r) < 0) {
> - fput(file);
> - r = -ENOMEM;
> - goto put_fd;
> - }
> kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
>
> fd_install(fd, file);
> --
> 2.36.1.124.g0e6072fb45-goog
>
next prev parent reply other threads:[~2022-06-16 18:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 17:58 [PATCH v2 0/5] KVM: Clean up debugfs+stats init/destroy Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-05-18 17:58 ` [PATCH v2 1/5] KVM: Shove vm stats_id init into kvm_create_vm() Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-06-16 17:46 ` Sean Christopherson
2022-06-16 17:46 ` Sean Christopherson
2022-06-16 17:48 ` Sean Christopherson
2022-06-16 17:48 ` Sean Christopherson
2022-05-18 17:58 ` [PATCH v2 2/5] KVM: Shove vcpu stats_id init into kvm_vcpu_init() Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-06-16 17:47 ` Sean Christopherson
2022-06-16 17:47 ` Sean Christopherson
2022-05-18 17:58 ` [PATCH v2 3/5] KVM: Get an fd before creating the VM Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-06-16 17:54 ` Sean Christopherson
2022-06-16 17:54 ` Sean Christopherson
2022-05-18 17:58 ` [PATCH v2 4/5] KVM: Actually create debugfs in kvm_create_vm() Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-06-16 18:03 ` Sean Christopherson [this message]
2022-06-16 18:03 ` Sean Christopherson
2022-05-18 17:58 ` [PATCH v2 5/5] KVM: Hoist debugfs_dentry init to kvm_create_vm_debugfs() (again) Oliver Upton
2022-05-18 17:58 ` Oliver Upton
2022-06-16 18:05 ` Sean Christopherson
2022-06-16 18:05 ` Sean Christopherson
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=Yqtwa03IWVNP4LLA@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maz@kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.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 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.