On Fri, 2024-02-16 at 07:52 -0800, Sean Christopherson wrote:
>
> FWIW, I'm not opposed to overhauling the gpc locking, I agree it's a mess. I
> just
> want to proceed slower than I would for a fix, it's a lot to digest.
Agreed. I'll do a *really* simple expansion of ->refresh_lock for the fix,
On Fri, Feb 16, 2024, Paul Durrant wrote:
> On 16/02/2024 13:04, David Woodhouse wrote:
> > On Thu, 2024-02-15 at 15:29 +, Paul Durrant wrote:
> > > From: David Woodhouse
> > >
> > > This function can race with kvm_gpc_deactivate(), which does not take
> > > the ->refresh_lock. This means kvm
On 16/02/2024 13:04, David Woodhouse wrote:
On Thu, 2024-02-15 at 15:29 +, Paul Durrant wrote:
From: David Woodhouse
This function can race with kvm_gpc_deactivate(), which does not take
the ->refresh_lock. This means kvm_gpc_deactivate() can wipe the ->pfn
and ->khva fields, and unmap the
On Thu, 2024-02-15 at 15:29 +, Paul Durrant wrote:
> From: David Woodhouse
>
> This function can race with kvm_gpc_deactivate(), which does not take
> the ->refresh_lock. This means kvm_gpc_deactivate() can wipe the ->pfn
> and ->khva fields, and unmap the latter, while hva_to_pfn_retry() has
From: David Woodhouse
This function can race with kvm_gpc_deactivate(), which does not take
the ->refresh_lock. This means kvm_gpc_deactivate() can wipe the ->pfn
and ->khva fields, and unmap the latter, while hva_to_pfn_retry() has
temporarily dropped its write lock on gpc->lock.
Then if hva_to
