Re: [PATCH V2 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses

[Jason Wang]

On 08/25/2015 07:33 PM, Michael S. Tsirkin wrote:
> On Tue, Aug 25, 2015 at 03:47:14PM +0800, Jason Wang wrote:
>> > We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
>> > and another is KVM_FAST_MMIO_BUS. This leads to issue:
>> > 
>> > - kvm_io_bus_destroy() knows nothing about the devices on two buses
>> >   points to a single dev. Which will lead double free [1] during exit.
>> > - wildcard eventfd ignores data len, so it was registered as a
>> >   kvm_io_range with zero length. This will fail the binary search in
>> >   kvm_io_bus_get_first_dev() when we try to emulate through
>> >   KVM_MMIO_BUS. This will cause userspace io emulation request instead
>> >   of a eventfd notification (virtqueue kick will be trapped by qemu
>> >   instead of vhost in this case).
>> > 
>> > Fixing this by don't register wildcard mmio eventfd on two
>> > buses. Instead, only register it in KVM_FAST_MMIO_BUS. This fixes the
>> > double free issue of kvm_io_bus_destroy(). For the arch/setups that
>> > does not utilize KVM_FAST_MMIO_BUS, before searching KVM_MMIO_BUS, try
>> > KVM_FAST_MMIO_BUS first to see it it has a match.
>> > 
>> > [1] Panic caused by double free:
>> > 
>> > CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
>> > Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
>> > task: ffff88009ae0c4b0 ti: ffff88020e7f0000 task.ti: ffff88020e7f0000
>> > RIP: 0010:[<ffffffffc07e25d8>]  [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
>> > RSP: 0018:ffff88020e7f3bc8  EFLAGS: 00010292
>> > RAX: dead000000200200 RBX: ffff8801ec19c900 RCX: 000000018200016d
>> > RDX: ffff8801ec19cf80 RSI: ffffea0008bf1d40 RDI: ffff8801ec19c900
>> > RBP: ffff88020e7f3bd8 R08: 000000002fc75a01 R09: 000000018200016d
>> > R10: ffffffffc07df6ae R11: ffff88022fc75a98 R12: ffff88021e7cc000
>> > R13: ffff88021e7cca48 R14: ffff88021e7cca50 R15: ffff8801ec19c880
>> > FS:  00007fc1ee3e6700(0000) GS:ffff88023e240000(0000) knlGS:0000000000000000
>> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > CR2: 00007f8f389d8000 CR3: 000000023dc13000 CR4: 00000000001427e0
>> > Stack:
>> > ffff88021e7cc000 0000000000000000 ffff88020e7f3be8 ffffffffc07e2622
>> > ffff88020e7f3c38 ffffffffc07df69a ffff880232524160 ffff88020e792d80
>> >  0000000000000000 ffff880219b78c00 0000000000000008 ffff8802321686a8
>> > Call Trace:
>> > [<ffffffffc07e2622>] ioeventfd_destructor+0x12/0x20 [kvm]
>> > [<ffffffffc07df69a>] kvm_put_kvm+0xca/0x210 [kvm]
>> > [<ffffffffc07df818>] kvm_vcpu_release+0x18/0x20 [kvm]
>> > [<ffffffff811f69f7>] __fput+0xe7/0x250
>> > [<ffffffff811f6bae>] ____fput+0xe/0x10
>> > [<ffffffff81093f04>] task_work_run+0xd4/0xf0
>> > [<ffffffff81079358>] do_exit+0x368/0xa50
>> > [<ffffffff81082c8f>] ? recalc_sigpending+0x1f/0x60
>> > [<ffffffff81079ad5>] do_group_exit+0x45/0xb0
>> > [<ffffffff81085c71>] get_signal+0x291/0x750
>> > [<ffffffff810144d8>] do_signal+0x28/0xab0
>> > [<ffffffff810f3a3b>] ? do_futex+0xdb/0x5d0
>> > [<ffffffff810b7028>] ? __wake_up_locked_key+0x18/0x20
>> > [<ffffffff810f3fa6>] ? SyS_futex+0x76/0x170
>> > [<ffffffff81014fc9>] do_notify_resume+0x69/0xb0
>> > [<ffffffff817cb9af>] int_signal+0x12/0x17
>> > Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 10 00 00
>> > RIP  [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
>> > RSP <ffff88020e7f3bc8>
>> > 
>> > Cc: Gleb Natapov <gleb@xxxxxxxxxx>
>> > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
>> > Cc: Michael S. Tsirkin <mst@xxxxxxxxxx>
>> > Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx>
> I'm worried that this slows down the regular MMIO.

I doubt whether or not it was measurable.

> Could you share performance #s please?
> You need a mix of len=0 and len=2 matches.

Ok.

> One solution for the first issue is to create two ioeventfd objects instead.

Sounds good.

> For the second issue, we could change bsearch compare function instead.

What do you mean by "second issue" ?

> Again, affects all devices to performance #s would be needed.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/