From owner-freebsd-net@freebsd.org Thu Dec 29 09:02:34 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 56012C96B15 for ; Thu, 29 Dec 2016 09:02:34 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 182921711; Thu, 29 Dec 2016 09:02:34 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id f201so54042947oib.0; Thu, 29 Dec 2016 01:02:34 -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=iZAsT+1mP15/m5IcXIZhGD2eybdSiPVrjEgM1dvTSeo=; b=BzgRlJVR7HMU2jkeI1Uu96OJFTqnbCfEYmEEwM0pbwvb8trmoa3Xx3tX+2Q4zEK4Bd 5wlkz6XdSOeoaoZ5s04UfoWMiNCbjGidOH8zD5n6zsyrcFt29KCJJKOtHEDAE0n3P7+f FOpWuE9TL4U5A621iH36QjK5Sen9KG9x1xj5yehkZMh5xsJirqADKrCL0mnLnoxwnHGq rztctjw0RdMTeY/a2O7lCyFB/rikla9lTATK5pH16nZUyoDjST4B2IeiNxrVW7arvjPl nspM7RqK9WpGUAr5w8yXvJPSaMb724SuuQzyPpcmREWzBEcPSMDV3FPKsWfgjEZob28q JVzQ== 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=iZAsT+1mP15/m5IcXIZhGD2eybdSiPVrjEgM1dvTSeo=; b=hUvPvNQzQceRHzgKY214D8jXvbnqxFkgS6xmgSONKHBemXWGMXUU3A08/AFXd3NYuA KvJ4sXYysNFVg670RUcxLTY96hcv5Tf6hzq1tr1PFZ7lDCMAZihE6JbolAuxms4q5Cp3 qUd8+MfdkQxtQBYa9IzoWRb8eyAVUGEq+2MApiBM9/FbzlJWkTgBSxWARM2U6maWrBrQ eADDbrlSAS62/ssIspDK0NZmNMFPvC2uGgQrqF5UdksfwDBCp2gHNHpoR+Rw8QusbEhp y8HjkM88frmr+arJC88pDF7nKfVncwEgznywnhahWLjRRXLHdRZrPQjuYRFjnLEBJti9 /+ng== X-Gm-Message-State: AIkVDXKmSAvYPSmDKFkBNrpgY7tD6PJB/MkW/VyF7+n6USe5JQUD6QzmtXnfhGX5JmLbLqKgs5jWOv/kwKqvDg== X-Received: by 10.157.16.16 with SMTP id h16mr21569932ote.40.1483002152827; Thu, 29 Dec 2016 01:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Thu, 29 Dec 2016 01:02:32 -0800 (PST) In-Reply-To: <9729046.di4hkLAXiP@ralph.baldwin.cx> References: <20161217222812.GA4979@ox> <2698793.0b4KyHrqck@ralph.baldwin.cx> <9729046.di4hkLAXiP@ralph.baldwin.cx> From: Vincenzo Maffione Date: Thu, 29 Dec 2016 10:02:32 +0100 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: John Baldwin Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Adrian Chadd , Giuseppe Lettieri , Luigi Rizzo , Navdeep Parhar Content-Type: multipart/mixed; boundary=001a1134f68e8558c00544c858c9 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: Thu, 29 Dec 2016 09:02:34 -0000 --001a1134f68e8558c00544c858c9 Content-Type: text/plain; charset=UTF-8 Ok, thanks for the clarification. I change the lock type to MTX_DEF (and did a test). I attached the new patch. 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 -- Vincenzo Maffione --001a1134f68e8558c00544c858c9 Content-Type: text/x-patch; charset=US-ASCII; name="netmap-fix-2.patch" Content-Disposition: attachment; filename="netmap-fix-2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ixa54qhv0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvbmV0bWFwL25ldG1hcF9mcmVlYnNkLmMgYi9zeXMvZGV2L25l dG1hcC9uZXRtYXBfZnJlZWJzZC5jCmluZGV4IGZkNDU5MmI3YjVhLi5kZDQxYzg1OTY1ZSAxMDA2 NDQKLS0tIGEvc3lzL2Rldi9uZXRtYXAvbmV0bWFwX2ZyZWVic2QuYworKysgYi9zeXMvZGV2L25l dG1hcC9uZXRtYXBfZnJlZWJzZC5jCkBAIC05Miw3ICs5Miw3IEBAIG5tX29zX3NlbGluZm9fdW5p bml0KE5NX1NFTElORk9fVCAqc2kpCiB2b2lkCiBubV9vc19pZm5ldF9sb2NrKHZvaWQpCiB7Ci0J SUZORVRfV0xPQ0soKTsKKwlJRk5FVF9STE9DSygpOwogfQogCiB2b2lkCkBAIC0xMDkwLDggKzEw OTAsOCBAQCBubV9rdGhyZWFkX3dvcmtlcih2b2lkICpkYXRhKQogCQkJCWNvbnRpbnVlOwogCQkJ fSBlbHNlIGlmIChubWstPnJ1bikgewogCQkJCS8qIHdhaXQgb24gZXZlbnQgd2l0aCBvbmUgc2Vj b25kIHRpbWVvdXQgKi8KLQkJCQltc2xlZXBfc3Bpbigodm9pZCAqKSh1aW50cHRyX3QpY3R4LT5j Zmcud2NoYW4sCi0JCQkJICAgICZubWstPndvcmtlcl9sb2NrLCAibm1rX2V2IiwgaHopOworCQkJ CW1zbGVlcCgodm9pZCAqKSh1aW50cHRyX3QpY3R4LT5jZmcud2NoYW4sCisJCQkJCSZubWstPndv cmtlcl9sb2NrLCAwLCAibm1rX2V2IiwgaHopOwogCQkJCW5tay0+c2NoZWR1bGVkKys7CiAJCQl9 CiAJCQltdHhfdW5sb2NrKCZubWstPndvcmtlcl9sb2NrKTsKQEAgLTExMjIsNyArMTEyMiw3IEBA IG5tX29zX2t0aHJlYWRfY3JlYXRlKHN0cnVjdCBubV9rdGhyZWFkX2NmZyAqY2ZnLCB1bnNpZ25l ZCBpbnQgY2ZndHlwZSwKIAlpZiAoIW5taykKIAkJcmV0dXJuIE5VTEw7CiAKLQltdHhfaW5pdCgm bm1rLT53b3JrZXJfbG9jaywgIm5tX2t0aHJlYWQgbG9jayIsIE5VTEwsIE1UWF9TUElOKTsKKwlt dHhfaW5pdCgmbm1rLT53b3JrZXJfbG9jaywgIm5tX2t0aHJlYWQgbG9jayIsIE5VTEwsIE1UWF9E RUYpOwogCW5tay0+d29ya2VyX2N0eC53b3JrZXJfZm4gPSBjZmctPndvcmtlcl9mbjsKIAlubWst Pndvcmtlcl9jdHgud29ya2VyX3ByaXZhdGUgPSBjZmctPndvcmtlcl9wcml2YXRlOwogCW5tay0+ d29ya2VyX2N0eC50eXBlID0gY2ZnLT50eXBlOwo= --001a1134f68e8558c00544c858c9--