From patchwork Mon Oct 28 08:28:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Asias He X-Patchwork-Id: 3100891 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 94C279F431 for ; Mon, 28 Oct 2013 08:29:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 13A11201CD for ; Mon, 28 Oct 2013 08:29:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 30624201BA for ; Mon, 28 Oct 2013 08:29:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755100Ab3J1I3j (ORCPT ); Mon, 28 Oct 2013 04:29:39 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:62145 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754680Ab3J1I3i (ORCPT ); Mon, 28 Oct 2013 04:29:38 -0400 Received: by mail-qc0-f172.google.com with SMTP id c9so3646718qcz.31 for ; Mon, 28 Oct 2013 01:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+K61FJKSB9S2kDqyJPZ//29T1uo7QMdkA7Sz1OM+dnA=; b=KNFny1AYxIKhqAv1x5FkE+RVn1FziGEyuHM+Ui6AjtFsCMRR1AYxCQ7vmLmJ30qDyH S70WzfP/Schc0AT/58dYh/Sx44FBHGz7SJXN4xfyrcbL06GQWuDAqgdr5XF20MntKxmx +b/7HJBbiycmykq25/6xlLZ4y2LBGjE1wsTLoVwZOUMHz9PXudDzwXGMfLdYeSbdpwY0 Op0GOYDDapI62n9nB3EhNzwk/souIVPUtTyJ7ulG3m3iETmNYI/CtAhZA5f6ZgrhkAsW n7QHO4y3e0H+WKUab23oQNN7gJ/YmKbSgJMSrX7HOnJvfjVXo3oNd0TY6E1bqh2OqIjq K0VQ== X-Received: by 10.229.7.65 with SMTP id c1mr27281216qcc.18.1382948977703; Mon, 28 Oct 2013 01:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.202.138 with HTTP; Mon, 28 Oct 2013 01:28:57 -0700 (PDT) In-Reply-To: <52651BA3.8030501@iki.fi> References: <20131021113528.GA657@ntm.wq.cz> <52651BA3.8030501@iki.fi> From: Asias He Date: Mon, 28 Oct 2013 16:28:57 +0800 Message-ID: Subject: Re: lkvm: virtio-net-rx general protection error To: Pekka Enberg Cc: Milan Kocian , KVM , Asias He , Sasha Levin , Cyrill Gorcunov Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Oct 21, 2013 at 8:18 PM, Pekka Enberg wrote: > On 10/21/13 1:35 PM, Milan Kocian wrote: >> >> hi, >> >> sorry for writing it directly to you but I didn't find better recipient. >> Does exist some mailing-list about lkvm? >> >> I found the crash in virtio-net-rx thread (I can reproduce it every time >> by 'aptitude update' in VM): >> >> traps: virtio-net-rx[28933] general protection ip:7f00dda3d107 >> sp:7f00c58f4de8 error:0 in libc-2.17.so[7f00dd90f000+1a2000] >> >> gdb backtrace: >> >> (gdb) bt >> #0 0x00007fb6a548e107 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x000000000041259c in memcpy_toiovecend (iov=0x7fb68d346ea0, >> iov@entry=0x7fb68d345e90, >> kdata=, kdata@entry=0x7fb68d346e90 "", >> offset=, len=) >> at util/iovec.c:70 >> #2 0x000000000040c66d in virtio_net_rx_thread (p=0x23688a0) at >> virtio/net.c:117 >> #3 0x00007fb6a5b2ee0e in start_thread () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #4 0x00007fb6a54489ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> >> >> I tried to add some printf to diagnose it but it isn't clear to me: >> >> virtio_net_rx_thread: before memcpy_toiovecend; copied: 0, len: 18890, >> iovsize: 4096, realiovsize: 4096 >> memcpy_toiovecend: offset: 0, len: 4096 >> memcpy_toiovecend: iov_len: 4096, len: 4096 >> virtio_net_rx_thread: before memcpy_toiovecend; copied: 4096, len: 18890, >> iovsize: 4096, realiovsize: 4096 >> memcpy_toiovecend: offset: 4096, len: 4096 >> memcpy_toiovecend: iov_len: 4096, len: 4096 >> memcpy_toiovecend: iov_len: 0, len: 4096 >> memcpy_toiovecend: iov_len: 0, len: 4096 >> . >> N x memcpy_toiovecend: iov_len: 0, len: 4096 >> . >> memcpy_toiovecend: iov_len: 0, len: 4096 >> memcpy_toiovecend: iov_len: 0, len: 4096 >> memcpy_toiovecend: iov_len: 1519143547641528320, len: 4096 >> memcpy_toiovecend: iov_len: 193827583623176, len: 4096 >> ./runlkvm.sh: line 2: 16090 Segmentation fault >> >> >> IMHO problem come when received len size is bigger than maximum >> of the dst iovec (realiovsize). Only iovec size is copied and in the next >> run isn't place to copy the rest of len size. >> >> So solution may be increase dst iovec size or send data in dst iovec >> to user (but i don't know how, I am not virtio expert :-)). > > > I'm CC'ing Asias, Sasha and others. Hello Milan, Does the attached patch fix your problem? Tested-by: Milan Kocian From b48eaeff7250bf7476c771e82cdbf20c3e85c4c9 Mon Sep 17 00:00:00 2001 From: Asias He Date: Mon, 28 Oct 2013 15:02:54 +0800 Subject: [PATCH 1/1] kvm-tools: Fix virtio-net iov memcpy We should skip copied bytes from the buffer not from the iov itself which memcpy_toiovecend does. Signed-off-by: Asias He --- tools/kvm/virtio/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c index 2c34996..3715aaf 100644 --- a/tools/kvm/virtio/net.c +++ b/tools/kvm/virtio/net.c @@ -114,7 +114,7 @@ static void *virtio_net_rx_thread(void *p) while (copied < len) { size_t iovsize = min(len - copied, iov_size(iov, in)); - memcpy_toiovecend(iov, buffer, copied, iovsize); + memcpy_toiovec(iov, buffer + copied, iovsize); copied += iovsize; if (has_virtio_feature(ndev, VIRTIO_NET_F_MRG_RXBUF)) hdr->num_buffers++; -- 1.8.3.1