[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZMwr06W5x/Lb19Wx@google.com>
Date: Thu, 3 Aug 2023 15:36:03 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Greg KH <gregkh@...uxfoundation.org>,
Sean Christopherson <seanjc@...gle.com>,
Roxana Bradescu <roxabee@...gle.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] kvm/vfio: ensure kvg instance stays around in
kvm_vfio_group_add()
On Thu, Aug 03, 2023 at 01:38:12PM -0600, Alex Williamson wrote:
> On Fri, 14 Jul 2023 15:45:32 -0700
> Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
>
> > kvm_vfio_group_add() creates kvg instance, links it to kv->group_list,
> > and calls kvm_vfio_file_set_kvm() with kvg->file as an argument after
> > dropping kv->lock. If we race group addition and deletion calls, kvg
> > instance may get freed by the time we get around to calling
> > kvm_vfio_file_set_kvm().
> >
> > Previous iterations of the code did not reference kvg->file outside of
> > the critical section, but used a temporary variable. Still, they had
> > similar problem of the file reference being owned by kvg structure and
> > potential for kvm_vfio_group_del() dropping it before
> > kvm_vfio_group_add() had a chance to complete.
> >
> > Fix this by moving call to kvm_vfio_file_set_kvm() under the protection
> > of kv->lock. We already call it while holding the same lock when vfio
> > group is being deleted, so it should be safe here as well.
> >
> > Fixes: 2fc1bec15883 ("kvm: set/clear kvm to/from vfio_group when group add/delete")
> > Reviewed-by: Alex Williamson <alex.williamson@...hat.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > ---
>
> Applied series to vfio next branch for v6.6. There's a minor rebase
> involved, so please double check the results:
>
> https://github.com/awilliam/linux-vfio/commits/next
Looks good to me, thanks!
--
Dmitry
Powered by blists - more mailing lists