From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbbHZFHY (ORCPT ); Wed, 26 Aug 2015 01:07:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45331 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbbHZFHX (ORCPT ); Wed, 26 Aug 2015 01:07:23 -0400 Message-ID: <55DD4984.7090903@redhat.com> Date: Wed, 26 Aug 2015 13:07:16 +0800 From: Jason Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: gleb@kernel.org, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, cornelia.huck@de.ibm.com Subject: Re: [PATCH V2 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses References: <1440488835-4388-1-git-send-email-jasowang@redhat.com> <1440488835-4388-2-git-send-email-jasowang@redhat.com> <20150825142523-mutt-send-email-mst@redhat.com> In-Reply-To: <20150825142523-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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:[] [] 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: >> > [] ioeventfd_destructor+0x12/0x20 [kvm] >> > [] kvm_put_kvm+0xca/0x210 [kvm] >> > [] kvm_vcpu_release+0x18/0x20 [kvm] >> > [] __fput+0xe7/0x250 >> > [] ____fput+0xe/0x10 >> > [] task_work_run+0xd4/0xf0 >> > [] do_exit+0x368/0xa50 >> > [] ? recalc_sigpending+0x1f/0x60 >> > [] do_group_exit+0x45/0xb0 >> > [] get_signal+0x291/0x750 >> > [] do_signal+0x28/0xab0 >> > [] ? do_futex+0xdb/0x5d0 >> > [] ? __wake_up_locked_key+0x18/0x20 >> > [] ? SyS_futex+0x76/0x170 >> > [] do_notify_resume+0x69/0xb0 >> > [] 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 [] ioeventfd_release+0x28/0x60 [kvm] >> > RSP >> > >> > Cc: Gleb Natapov >> > Cc: Paolo Bonzini >> > Cc: Michael S. Tsirkin >> > Signed-off-by: Jason Wang > 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. >