From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F4062C43218 for ; Thu, 25 Apr 2019 17:03:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 79A7620684 for ; Thu, 25 Apr 2019 17:03:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727331AbfDYRDs (ORCPT ); Thu, 25 Apr 2019 13:03:48 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:37124 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbfDYRDs (ORCPT ); Thu, 25 Apr 2019 13:03:48 -0400 Received: by mail-qt1-f196.google.com with SMTP id e2so170854qtb.4 for ; Thu, 25 Apr 2019 10:03:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hZDKdCBi67jaqhV3HRQLb+m4tgtxa8QTVh6YzX4UJ0s=; b=bnKmrK0sa+h92t3BsBpXWC/pAd5XW/k97lB8d6VNqU3sak2KQe05nZSLUQzkUfvYKw 3IvIRY91Y9VRL9PpJBmVE5VY7swIYTPXijXqhq9gpCwj62fcob2gUlikxCLs7As6LW9i jmpeVee/8LBuUGYuaSz6qpM2J1ldYs6y4sE3IN3eo/7tIZ4F4qctux3Qa0O7fN7/TYoo tmzFq+zQs4YwPK26WPyKDN+aJg2YFZShlRch78QOfZgKG4zDhsyNIEZzb+c7FwNygEfk kgiKDwhFR/kcdwi2gu234FIb9OTMbPB4F0p4ZiQG5fp20I0P9QIIchnSjVTMjGiT3MIx Hsdg== X-Gm-Message-State: APjAAAXqJqpMu8SlCrHdf/EBM3RZet82dtMajhjVGwe5zsWaIX8vvWQ/ Aygg/BOuwMMlGR8axIlTDDIiOQ== X-Google-Smtp-Source: APXvYqxrCpWH7hu45VHdA1KjdQQdQGKXUyPmVFQ0iR2IwwlTiNOm3jVLAz3adc5LgLlcRY04qiiTvg== X-Received: by 2002:ac8:2a5d:: with SMTP id l29mr32704877qtl.139.1556211827734; Thu, 25 Apr 2019 10:03:47 -0700 (PDT) Received: from redhat.com (pool-173-76-105-71.bstnma.fios.verizon.net. [173.76.105.71]) by smtp.gmail.com with ESMTPSA id k63sm5271037qkf.97.2019.04.25.10.03.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Apr 2019 10:03:46 -0700 (PDT) Date: Thu, 25 Apr 2019 13:03:39 -0400 From: "Michael S. Tsirkin" To: Toshiaki Makita Cc: David Ahern , Jesper Dangaard Brouer , Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , "netdev@vger.kernel.org" , Jason Wang Subject: Re: virtio_net: suspicious RCU usage with xdp Message-ID: <20190425130319-mutt-send-email-mst@kernel.org> References: <20190424132533-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 25, 2019 at 01:58:48PM +0900, Toshiaki Makita wrote: > On 2019/04/25 2:37, Michael S. Tsirkin wrote: > > On Wed, Apr 24, 2019 at 11:13:42AM -0600, David Ahern wrote: > >> seeing an RCU warning testing xdp with virtio net. net-next as of commit > >> b2f97f7de2f6a4df8e431330cf467576486651c5. No obvious changes so hoping > >> this rings a bell with someone else. > >> > >> > >> [ 121.990304] ============================= > >> [ 121.991488] WARNING: suspicious RCU usage > >> [ 121.992392] 5.1.0-rc5+ #60 Not tainted > >> [ 121.993220] ----------------------------- > >> [ 121.994158] /home/dsa/kernel-3.git/drivers/net/virtio_net.c:516 > >> suspicious rcu_dereference_check() usage! > >> [ 121.996284] > >> other info that might help us debug this: > >> > >> [ 121.997988] > >> rcu_scheduler_active = 2, debug_locks = 1 > >> [ 121.999321] no locks held by swapper/1/0. > >> [ 122.000328] > >> stack backtrace: > >> [ 122.001253] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.1.0-rc5+ #60 > >> [ 122.002474] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > >> BIOS 1.11.1-1 04/01/2014 > >> [ 122.004141] Call Trace: > >> [ 122.004651] > >> [ 122.005082] dump_stack+0x7e/0xbb > >> [ 122.005757] lockdep_rcu_suspicious+0x102/0x10b > >> [ 122.006654] virtnet_xdp_xmit+0x104/0x4fe > >> [ 122.007447] ? kasan_check_read+0x11/0x13 > >> [ 122.008267] ? mergeable_rx_buffer_size_show+0x163/0x163 > >> [ 122.009299] ? __asan_loadN+0xf/0x11 > >> [ 122.010010] ? pvclock_clocksource_read+0xfa/0x189 > >> [ 122.010975] bq_xmit_all+0xdc/0x358 > >> [ 122.011699] __dev_map_flush+0xc2/0xef > >> [ 122.012472] xdp_do_flush_map+0x5b/0x74 > >> [ 122.013238] virtnet_poll+0x58f/0x679 > > > > Well virtnet_xdp_xmit seems to be called from .ndo_xdp_xmit > > and that isn't in an RCU read-side critical section. > > > > Looks like we just need to add RCU read lock/unlock. > > Like the below perhaps? > > > > This issue was introduced by 8dcc5b0ab0 however I find it > > Probably not 8dcc5b0ab0, but 5d053f9da431 ("bpf: devmap prepare xdp > frames for bulking"). > > > inelegant that we need to do checks in each driver, > > and add RCU locks just for a startup initialization issue. > > Can't XDP core make sure the callback isn't invoked > > at an inappropriate time instead? > > Before commit 5d053f9da431, .ndo_xdp_xmit() should have always been > called under RCU. After the commit, xdp_do_flush_map() also can trigger > .ndo_xdp_xmit() but we forgot to add RCU read lock there? > I guess veth has the same problem and I feel like it should be fixed in > __dev_map_flush(). dev_map_flush_old() needs to be cared too. I don't have a problem either way. Jesper, what do you think? > -- > Toshiaki Makita