lkml.org 
[lkml]   [2022]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5.17 183/219] KVM: Dont create VM debugfs files outside of the VM directory
On Mon, Apr 18, 2022 at 10:14:42AM -0700, Oliver Upton wrote:
> Hi Greg,
>
> On Mon, Apr 18, 2022 at 5:24 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > From: Oliver Upton <oupton@google.com>
> >
> > commit a44a4cc1c969afec97dbb2aedaf6f38eaa6253bb upstream.
> >
> > Unfortunately, there is no guarantee that KVM was able to instantiate a
> > debugfs directory for a particular VM. To that end, KVM shouldn't even
> > attempt to create new debugfs files in this case. If the specified
> > parent dentry is NULL, debugfs_create_file() will instantiate files at
> > the root of debugfs.
> >
> > For arm64, it is possible to create the vgic-state file outside of a
> > VM directory, the file is not cleaned up when a VM is destroyed.
> > Nonetheless, the corresponding struct kvm is freed when the VM is
> > destroyed.
> >
> > Nip the problem in the bud for all possible errant debugfs file
> > creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing,
> > debugfs_create_file() will fail instead of creating the file in the root
> > directory.
> >
> > Cc: stable@kernel.org
> > Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions")
> > Signed-off-by: Oliver Upton <oupton@google.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/20220406235615.1447180-2-oupton@google.com
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Can you drop this patch from stable for the time being? There's a bug
> in it because KVM does init/destroy awkwardly. Sean working on a fix
> [1].
>
> [1]: https://lore.kernel.org/kvm/20220415004622.2207751-1-seanjc@google.com/

Will do, I'll go drop it from everywhere.

greg k-h

\
 
 \ /
  Last update: 2022-04-19 09:33    [W:0.109 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site