From owner-freebsd-net@freebsd.org Fri Dec 30 14:40:08 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D85FC97975 for ; Fri, 30 Dec 2016 14:40:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF2841104; Fri, 30 Dec 2016 14:40:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wj0-x243.google.com with SMTP id kp2so60941053wjc.0; Fri, 30 Dec 2016 06:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xxs8oMcLAvvLck0uuFk46dtlnpk3wQ80+kp57paAKoA=; b=gZt+PQxuT3Y4ya9nwNBkmFqeXjqGOxpy6eru0Y+wErCMhIhsmpMJIY1b47IadxJiJE AB2uq+Dm/PtP3S34yJBQdgHVnwyU5HhsGf5/WsBq5+ejmCPDqgym+iYhuG5WntGr6nwR LHB927g+3ttWLoOPwMPKPyPVM17x4UTvoLZnUKhdJ4NQJ6QG6Byb6Qsln0w5vR10V2Qw +o6fO5L3UUloMtsTsgaXAKwEuC5UPxB7a+/R8Wa3eLjDPOG1hPjMF1DNtxBSZnjjtEYt EVVMlENyqs7J28/BzlPmnxf4epEaDvc7fKH1/TBxV8VkvNA5Uj2p8Sbf/5kL+51+B13d 6ivw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xxs8oMcLAvvLck0uuFk46dtlnpk3wQ80+kp57paAKoA=; b=HFbQ7OICRnpKWR/HIAMAMlKenbE7cP7GTdYIkJEXh/Z/C+vShC1qsGTBVcSmbEJfl3 DRhBGakCQ3x98h4lq+whwVx8D06Bo392qK/eZqCKqugWPxJlgUIv1eLQM0feRhlz+qwb 0kl1vr65gL5gR/Bfw+EGxQX4XpJMMZwVL/modAhL5CAHFk2L7iE1ejQ5Wa6LCfHD/elP +AlcGyc+plIN3pQBitQ3oJ7vlShorBYPbxY1h+NYdFbvvOZrFu3i5PbvwhtJOOxJIdKt oee/fEDXKr4umXvVS+mlvNVJZ3srcXdcpySspIja474w+sv2MRpoMxkZPSUURkZxdUmA oU2A== X-Gm-Message-State: AIkVDXICbXUic3dqL/Y575WMV4UAAB1VAi6N6TQoAwiUIQBcKyq3k1Akzt8w1UGeKr/SOu6G0t8E02VRXhMHjA== X-Received: by 10.194.205.34 with SMTP id ld2mr39875937wjc.211.1483108806201; Fri, 30 Dec 2016 06:40:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.1 with HTTP; Fri, 30 Dec 2016 06:40:05 -0800 (PST) In-Reply-To: References: <20161217222812.GA4979@ox> <9729046.di4hkLAXiP@ralph.baldwin.cx> <28018209.hrnUzHgbYH@ralph.baldwin.cx> From: Adrian Chadd Date: Fri, 30 Dec 2016 06:40:05 -0800 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: Vincenzo Maffione Cc: John Baldwin , "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 14:40:08 -0000 Hi, I'll do it in a sec. -a On 30 December 2016 at 01:11, Vincenzo Maffione wrote: > Ok! Can anyone commit this? > Luigi seems to be ok with the change. > > Thanks, > Vincenzo > > 2016-12-29 19:16 GMT+01:00 John Baldwin : >> On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote: >>> Ok, thanks for the clarification. I change the lock type to MTX_DEF >>> (and did a test). I attached the new patch. >> >> Looks good to me, thanks! >> >>> Cheers, >>> Vincenzo >>> >>> 2016-12-29 2:06 GMT+01:00 John Baldwin : >>> > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote: >>> >> Hi, >>> >> The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which >>> >> in turn is called by nm_pt_host_notify(). The latter function is a >>> >> callback that may be called by a driver interrupt service routine; >>> >> more precisely this happens when the driver calls netmap_tx_irq() or >>> >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to >>> >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this? >>> > >>> > It depends. Most interrupt handlers run in ithreads and can use MTX_DEF. >>> > Only interrupt handlers that run from a filter are restricted to using >>> > MTX_SPIN. Looking at all the calls to netmap_[tr]x_irq() in the tree, >>> > they are all done from contexts that are safe to use MTX_DEF (and in >>> > general they have to be as the equivalent code for the non-netmap case >>> > is calling routines like if_input or m_freem that can't be invoked from >>> > a filter either). >>> > >>> >> >>> >> Cheers, >>> >> Vincenzo >>> >> >>> >> 2016-12-28 19:06 GMT+01:00 John Baldwin : >>> >> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to >>> >> > be a smaller patch and probably more correct for FreeBSD. >>> >> > >>> >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote: >>> >> >> sure go ahead and thank you! >>> >> >> >>> >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd wrote: >>> >> >> > ok, does anyone mind if I commit it as-is? >>> >> >> > >>> >> >> > >>> >> >> > -a >>> >> >> > >>> >> >> > >>> >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione wrote: >>> >> >> >> Hi Luigi, >>> >> >> >> I attached a minimal change containing two fixes: >>> >> >> >> >>> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related >>> >> >> >> to this thread >>> >> >> >> - use the proper locking functions for the "worker_lock", unrelated >>> >> >> >> but needed to avoid the O.S. to trap because of a mismatch between >>> >> >> >> MTX_SPIN and MTX_DEF. >>> >> >> >> >>> >> >> >> Cheers, >>> >> >> >> Vincenzo >>> >> >> >> >>> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo : >>> >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione >>> >> >> >>> wrote: >>> >> >> >>>> Hi, >>> >> >> >>>> There is no commit related to that in the FreeBSD svn or git. >>> >> >> >>>> >>> >> >> >>>> The fix has been published to the github netmap repository here >>> >> >> >>>> (branch master): https://github.com/luigirizzo/netmap >>> >> >> >>>> >>> >> >> >>>> What we should do is to import all the recent updates from the github >>> >> >> >>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me >>> >> >> >>>> know. >>> >> >> >>> >>> >> >> >>> I just checked and the diff between FreeBSD head and netmap head >>> >> >> >>> in github is almost 3k lines due to a lot of recent refactoring. >>> >> >> >>> So, if there is an easy way to extract just the locking change that would >>> >> >> >>> be preferable as an interim solution. >>> >> >> >>> >>> >> >> >>> cheers >>> >> >> >>> luigi >>> >> >> >>> >>> >> >> >>>> >>> >> >> >>>> Cheers, >>> >> >> >>>> Vincenzo >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd : >>> >> >> >>>>> hi, >>> >> >> >>>>> >>> >> >> >>>>> What's the commit? We should get it into -HEAD asap. >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> -adrian >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> On 20 December 2016 at 01:25, Vincenzo Maffione wrote: >>> >> >> >>>>>> Ok, applied to the netmap github repo. >>> >> >> >>>>>> This fix will be published when Luigi does the next commit on FreeBSD. >>> >> >> >>>>>> >>> >> >> >>>>>> Cheers, >>> >> >> >>>>>> Vincenzo >>> >> >> >>>>>> >>> >> >> >>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar : >>> >> >> >>>>>>> IFNET_RLOCK will work, thanks. >>> >> >> >>>>>>> >>> >> >> >>>>>>> Navdeep >>> >> >> >>>>>>> >>> >> >> >>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione wrote: >>> >> >> >>>>>>>> Hi Navdeep, >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Indeed, we have reviewed the code, and we think it is ok to >>> >> >> >>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using >>> >> >> >>>>>>>> IFNET_WLOCK(). >>> >> >> >>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue. >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie(). >>> >> >> >>>>>>>> However, on Linux the same lock is also needed to protect the call to >>> >> >> >>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified" >>> >> >> >>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock. >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Does this make sense to you? Would it be easy for you to make a quick >>> >> >> >>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK? >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> Thanks, >>> >> >> >>>>>>>> Vincenzo >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar : >>> >> >> >>>>>>>>> Luigi, Vincenzo, >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's >>> >> >> >>>>>>>>> native netmap support. The problem is that netmap_hw_reg now holds an >>> >> >> >>>>>>>>> rw_lock around the driver's netmap_on/off routines. It has always been >>> >> >> >>>>>>>>> safe for the driver to sleep during these operations but now it panics >>> >> >> >>>>>>>>> instead. >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to disallow >>> >> >> >>>>>>>>> sleep on the control path. >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> Regards, >>> >> >> >>>>>>>>> Navdeep >>> >> >> >>>>>>>>> >>> >> >> >>>>>>>>> begin_synchronized_op with the following non-sleepable locks held: >>> >> >> >>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xffffffff8271d680) locked @ >>> >> >> >>>>>>>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95 >>> >> >> >>>>>>>>> stack backtrace: >>> >> >> >>>>>>>>> #0 0xffffffff810837a5 at witness_debugger+0xe5 >>> >> >> >>>>>>>>> #1 0xffffffff81084d88 at witness_warn+0x3b8 >>> >> >> >>>>>>>>> #2 0xffffffff83ef2bcc at begin_synchronized_op+0x6c >>> >> >> >>>>>>>>> #3 0xffffffff83f14beb at cxgbe_netmap_reg+0x5b >>> >> >> >>>>>>>>> #4 0xffffffff809846f1 at netmap_hw_reg+0x81 >>> >> >> >>>>>>>>> #5 0xffffffff809806de at netmap_do_regif+0x19e >>> >> >> >>>>>>>>> #6 0xffffffff8098121d at netmap_ioctl+0x7ad >>> >> >> >>>>>>>>> #7 0xffffffff8098682f at freebsd_netmap_ioctl+0x5f >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> >>> >> >> >>>>>>>> -- >>> >> >> >>>>>>>> Vincenzo Maffione >>> >> >> >>>>>>>> _______________________________________________ >>> >> >> >>>>>>>> freebsd-net@freebsd.org mailing list >>> >> >> >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >> >> >>>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> >>> >> >> >>>>>> -- >>> >> >> >>>>>> Vincenzo Maffione >>> >> >> >>>>>> _______________________________________________ >>> >> >> >>>>>> freebsd-net@freebsd.org mailing list >>> >> >> >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >> >> >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> -- >>> >> >> >>>> Vincenzo Maffione >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> -- >>> >> >> >>> -----------------------------------------+------------------------------- >>> >> >> >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >>> >> >> >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>> >> >> >>> TEL +39-050-2217533 . via Diotisalvi 2 >>> >> >> >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> >> >> >>> -----------------------------------------+------------------------------- >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> Vincenzo Maffione >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > -- >>> >> > John Baldwin >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > John Baldwin >>> >>> >>> >>> >> >> >> -- >> John Baldwin > > > > -- > Vincenzo Maffione