On Tue, Apr 20, 2021, Paolo Bonzini wrote:
> On 19/04/21 17:09, Sean Christopherson wrote:
> > > - this loses the rwsem fairness. On the other hand, mm/mmu_notifier.c's
> > > own interval-tree-based filter is also using a similar mechanism that is
> > > likewise not fair, so it should be okay.
>
On 19/04/21 17:09, Sean Christopherson wrote:
- this loses the rwsem fairness. On the other hand, mm/mmu_notifier.c's
own interval-tree-based filter is also using a similar mechanism that is
likewise not fair, so it should be okay.
The one concern I had with an unfair mechanism of this nature
On Mon, Apr 19, 2021, Paolo Bonzini wrote:
> On 19/04/21 10:49, Wanpeng Li wrote:
> > I saw this splatting:
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 5.12.0-rc3+ #6 Tainted: G OE
> >
On 19/04/21 10:49, Wanpeng Li wrote:
I saw this splatting:
==
WARNING: possible circular locking dependency detected
5.12.0-rc3+ #6 Tainted: G OE
--
qemu-system-x86/3069
On Fri, 2 Apr 2021 at 08:59, Sean Christopherson wrote:
>
> Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
> notifications. Because mmu_notifier_count must be modified while holding
> mmu_lock for write, and must always be paired across start->end to stay
> balanced, lock
On Fri, Apr 02, 2021, Paolo Bonzini wrote:
> On 02/04/21 02:56, Sean Christopherson wrote:
> > Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
> > notifications. Because mmu_notifier_count must be modified while holding
> > mmu_lock for write, and must always be paired across
On 02/04/21 02:56, Sean Christopherson wrote:
Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
notifications. Because mmu_notifier_count must be modified while holding
mmu_lock for write, and must always be paired across start->end to stay
balanced, lock elision must happen
7 matches
Mail list logo