From owner-freebsd-net@freebsd.org Tue Dec 20 09:25:38 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 6114EC88FFB for ; Tue, 20 Dec 2016 09:25:38 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 36223172F; Tue, 20 Dec 2016 09:25:38 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x242.google.com with SMTP id f201so23074030oib.0; Tue, 20 Dec 2016 01:25:38 -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=yZ5sMinK6ybgyKGrgUaUql2xMtPgtYkGJdun77l6mWQ=; b=MQiUe4GOTiHc5J0dOpPK9mW8BswPbYhAnBcb6Acm+rVblCMic/8aJ0su3KtlGC/R8I MoqEXYrH+ZHxlaOzhkwwUy8R8qUk0xB3O/iwKELmCiHcH/MThtzkVd8KfXTHLJPH4M2J 2W8AyZyz5itR572XdL8A+tdO+MtPYJqYyo4y6B98VUxcUhXSUxiQvWaYKZ+5vHx6pgqO d9Op6iE3hL2TLXAzWWOStgZJr2kqROP72MBedFQiQPC9pWDwci/1/22VR4eoK+jNR+Te U5G63ctBYwhCDseglQa0YKv+psl40Vph19QEcBtqi8Ze9Iir+n6AckbG1LRKJ14YVeaA xmMQ== 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=yZ5sMinK6ybgyKGrgUaUql2xMtPgtYkGJdun77l6mWQ=; b=cS2b5c1Hi7mBISItlvo/TmCyBmX8R1x24RZZgjapHfkRMC/dOQeDrYT1L7JFI/sWsr HsPm+p1Krc3vB4NAH1Q/GZKCYNtgFo9j09pAmM+fuEeg6m51azq8M1ZVHZhnw15nhlao 3GoYW8CLrYZmea5ZIWnxRl3KAa5hCZtu85WZuZJdWI8z+BlZS/kpFmfzBywI+AFwF48C 7c0ClXLI+YfE3dEWUeQgmv6eSTGAAoImVX2BsJFfvfp/KcN/gzr06bHoTrXcDb/AMCVf howhLcl9Iq+0fM7O1w8Smu6J44hOh2HySNrJdA2xnl+06dhoPcAHyaAuIt1GumJfmnEi OgDA== X-Gm-Message-State: AIkVDXKY3kzDdwPLIhNQ68DiiaksESYRTUsPXKZAp/TTpNWwjY/uOI84vxCbgExDHwxt28m4dqInelntDQTjWw== X-Received: by 10.202.185.198 with SMTP id j189mr10658934oif.32.1482225937253; Tue, 20 Dec 2016 01:25:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.200 with HTTP; Tue, 20 Dec 2016 01:25:36 -0800 (PST) In-Reply-To: References: <20161217222812.GA4979@ox> From: Vincenzo Maffione Date: Tue, 20 Dec 2016 10:25:36 +0100 Message-ID: Subject: Re: cxgbe's native netmap support broken since r307394 To: Navdeep Parhar Cc: Luigi Rizzo , "freebsd-net@freebsd.org" , Giuseppe Lettieri 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: Tue, 20 Dec 2016 09:25:38 -0000 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