On Mon, Dec 18, 2017 at 09:50:04AM +0100, Paolo Bonzini wrote:
> On 18/12/2017 09:30, David Hildenbrand wrote:
> > The ugly thing in kvm_irqfd_assign() is that we access irqfd without
> > holding a lock. I think that should rather be fixed than working around
> > that issue. (e.g. lock() -> lookup
On 2017年12月19日 18:41, Paolo Bonzini wrote:
> On 19/12/2017 07:35, Lan Tianyu wrote:
>> On 2017年12月18日 16:50, Paolo Bonzini wrote:
>>> On 18/12/2017 09:30, David Hildenbrand wrote:
The ugly thing in kvm_irqfd_assign() is that we access irqfd without
holding a lock. I think that should rath
On 19/12/2017 07:35, Lan Tianyu wrote:
> On 2017年12月18日 16:50, Paolo Bonzini wrote:
>> On 18/12/2017 09:30, David Hildenbrand wrote:
>>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without
>>> holding a lock. I think that should rather be fixed than working around
>>> that issue. (
On 2017年12月18日 16:50, Paolo Bonzini wrote:
> On 18/12/2017 09:30, David Hildenbrand wrote:
>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without
>> holding a lock. I think that should rather be fixed than working around
>> that issue. (e.g. lock() -> lookup again -> verify still i
Hi David:
Thanks for your review.
On 2017年12月18日 16:30, David Hildenbrand wrote:
> On 18.12.2017 00:40, Lan Tianyu wrote:
>> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free.
>> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel
>> for same eve
On 18/12/2017 10:08, David Hildenbrand wrote:
> On 18.12.2017 09:50, Paolo Bonzini wrote:
>> On 18/12/2017 09:30, David Hildenbrand wrote:
>>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without
>>> holding a lock. I think that should rather be fixed than working around
>>> that is
On 18.12.2017 09:50, Paolo Bonzini wrote:
> On 18/12/2017 09:30, David Hildenbrand wrote:
>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without
>> holding a lock. I think that should rather be fixed than working around
>> that issue. (e.g. lock() -> lookup again -> verify still in
On 18/12/2017 09:30, David Hildenbrand wrote:
> The ugly thing in kvm_irqfd_assign() is that we access irqfd without
> holding a lock. I think that should rather be fixed than working around
> that issue. (e.g. lock() -> lookup again -> verify still in list ->
> unlock())
I wonder if it's even sim
On 18.12.2017 00:40, Lan Tianyu wrote:
> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free.
> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel
> for same eventfd. When assign path hasn't been finished after irqfd
> has been added to kvm->irqfds.items l
Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free.
Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel
for same eventfd. When assign path hasn't been finished after irqfd
has been added to kvm->irqfds.items list, another thead may deassign the
eventfd and
10 matches
Mail list logo