From patchwork Tue Feb 13 14:15:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jason Wang X-Patchwork-Id: 10216433 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5AA5160329 for ; Tue, 13 Feb 2018 14:15:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 498FC28CE6 for ; Tue, 13 Feb 2018 14:15:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3E1A628CEE; Tue, 13 Feb 2018 14:15:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9C4C628CE6 for ; Tue, 13 Feb 2018 14:15:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965037AbeBMOP1 (ORCPT ); Tue, 13 Feb 2018 09:15:27 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58792 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964954AbeBMOP1 (ORCPT ); Tue, 13 Feb 2018 09:15:27 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 76BD3123AA0; Tue, 13 Feb 2018 14:15:26 +0000 (UTC) Received: from [10.72.12.23] (ovpn-12-23.pek2.redhat.com [10.72.12.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C89CB289D; Tue, 13 Feb 2018 14:15:23 +0000 (UTC) Subject: Re: [BUG] tuntap: using smp_processor_id() in preemptible from xdp flush To: Christoffer Dall Cc: davem@davemloft.net, Marc Zyngier , kvm@vger.kernel.org References: <20180213132147.GH23189@cbox> From: Jason Wang Message-ID: Date: Tue, 13 Feb 2018 22:15:20 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180213132147.GH23189@cbox> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 13 Feb 2018 14:15:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 13 Feb 2018 14:15:26 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jasowang@redhat.com' RCPT:'' Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 2018年02月13日 21:21, Christoffer Dall wrote: > Hi Jason, > > With v4.16-rc1 I see a low of these when running my KVM/ARM test loop: > > BUG: using smp_processor_id() in preemptible [00000000] code: vhost-2877/2900 > caller is debug_smp_processor_id+0x1c/0x28 > CPU: 0 PID: 2900 Comm: vhost-2877 Not tainted 4.16.0-rc1 #1333 > Hardware name: APM X-Gene Mustang board (DT) > Call trace: > dump_backtrace+0x0/0x180 > show_stack+0x24/0x30 > dump_stack+0x8c/0xac > check_preemption_disabled+0xf8/0x100 > debug_smp_processor_id+0x1c/0x28 > xdp_do_flush_map+0x24/0x48 > tun_sendmsg+0x90/0xa0 > handle_tx+0x254/0x548 > handle_tx_kick+0x20/0x30 > vhost_worker+0xc0/0x158 > kthread+0x104/0x130 > ret_from_fork+0x10/0x1c > > I confirmed that reverting > 762c330d670e, "tuntap: add missing xdp flush", 2018-02-07 > solves the problem for me. > > I'm not at all familiar with this part of the kernel and not sure what > the proper fix is. I'd be grateful if you could take a look and I'm > happy to help test etc. > > Thanks, > -Christoffer Hi Christoffer: Thanks for the reporting. Looking like it was because I try hard to do batching for XDP devmap which seems a little hard since it assumes XDP was running inside NAPI. Simply disable preemption can silent the warning but may lead other issue e.g miss some CPU where the process run previously. The only way is to disable batching now. Please help to test the attached patch. Thanks Tested-by: Christoffer Dall From 289267a71bc417bd86aa0040d2f3822e9c5aee37 Mon Sep 17 00:00:00 2001 From: Jason Wang Date: Tue, 13 Feb 2018 22:06:04 +0800 Subject: [PATCH] tuntap: try not batch packets for devmap Commit 762c330d670e ("tuntap: add missing xdp flush") tries to fix the devmap stall caused by missed xdp flush by counting the pending xdp redirected packets and flush when it exceeds NAPI_POLL_WEIGHT or MSG_MORE is clear. This may lead BUG() since xdp_do_flush() was called under process context with preemption enabled. Simply disable preemption may silent the warning but be not enough since process may move between different CPUS during a batch which cause xdp_do_flush() misses some CPU where the process run previously. For -net, fix this by simply calling xdp_do_flush() immediately after xdp_do_redirect(), a side effect is that this removes any possibility of batching which could be addressed in the future. Reported-by: Christoffer Dall Fixes: 762c330d670e ("tuntap: add missing xdp flush") Signed-off-by: Jason Wang --- drivers/net/tun.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 17e496b..6a4cd97 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -181,7 +181,6 @@ struct tun_file { struct tun_struct *detached; struct ptr_ring tx_ring; struct xdp_rxq_info xdp_rxq; - int xdp_pending_pkts; }; struct tun_flow_entry { @@ -1666,10 +1665,10 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun, case XDP_REDIRECT: get_page(alloc_frag->page); alloc_frag->offset += buflen; - ++tfile->xdp_pending_pkts; err = xdp_do_redirect(tun->dev, &xdp, xdp_prog); if (err) goto err_redirect; + xdp_do_flush_map(); rcu_read_unlock(); return NULL; case XDP_TX: @@ -1988,11 +1987,6 @@ static ssize_t tun_chr_write_iter(struct kiocb *iocb, struct iov_iter *from) result = tun_get_user(tun, tfile, NULL, from, file->f_flags & O_NONBLOCK, false); - if (tfile->xdp_pending_pkts) { - tfile->xdp_pending_pkts = 0; - xdp_do_flush_map(); - } - tun_put(tun); return result; } @@ -2330,12 +2324,6 @@ static int tun_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len) m->msg_flags & MSG_DONTWAIT, m->msg_flags & MSG_MORE); - if (tfile->xdp_pending_pkts >= NAPI_POLL_WEIGHT || - !(m->msg_flags & MSG_MORE)) { - tfile->xdp_pending_pkts = 0; - xdp_do_flush_map(); - } - tun_put(tun); return ret; } @@ -3167,7 +3155,6 @@ static int tun_chr_open(struct inode *inode, struct file * file) sock_set_flag(&tfile->sk, SOCK_ZEROCOPY); memset(&tfile->tx_ring, 0, sizeof(tfile->tx_ring)); - tfile->xdp_pending_pkts = 0; return 0; } -- 2.7.4