Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Nov 2019 20:16:23 -0800
From:      Gleb Smirnoff <glebius@freebsd.org>
To:        Renato Botelho <garga@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r354149 - head/sys/net
Message-ID:  <20191109041623.GS2195@FreeBSD.org>
In-Reply-To: <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org>
References:  <201910291736.x9THa6Gd018030@repo.freebsd.org> <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--qp4W5+cUSnZs0RIF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

  Renato,

can you please try out the attached patch?

On Fri, Nov 08, 2019 at 01:27:30PM -0300, Renato Botelho wrote:
R> On 29/10/19 14:36, Gleb Smirnoff wrote:
R> > Author: glebius
R> > Date: Tue Oct 29 17:36:06 2019
R> > New Revision: 354149
R> > URL: https://svnweb.freebsd.org/changeset/base/354149
R> > 
R> > Log:
R> >   There is a long standing problem with multicast programming for NICs
R> >   and IPv6.  With IPv6 we may call if_addmulti() in context of processing
R> >   of an incoming packet.  Usually this is interrupt context.  While most
R> >   of the NIC drivers are able to reprogram multicast filters without
R> >   sleeping, some of them can't.  An example is e1000 family of drivers.
R> >   With iflib conversion the problem was somewhat hidden.  Iflib processes
R> >   packets in private taskqueue, so going to sleep doesn't trigger an
R> >   assertion.  However, the sleep would block operation of the driver and
R> >   following incoming packets would fill the ring and eventually would
R> >   start being dropped.  Enabling epoch for the full time of a packet
R> >   processing again started to trigger assertions for e1000.
R> >   
R> >   Fix this problem once and for all using a general taskqueue to call
R> >   if_ioctl() method in all cases when if_addmulti() is called in a
R> >   non sleeping context.  Note that nobody cares about returned value.
R> >   
R> >   Reviewed by:	hselasky, kib
R> >   Differential Revision:	  https://reviews.freebsd.org/D22154
R> 
R> Hi Gleb,
R> 
R> I upgraded my laptop running 13-CURRENT from r354133 to r354437 and it
R> crashed during boot as you can see in the pictures [1].  It seems like
R> it crashed while it was configuring network.
R> 
R> After bisect I managed to boot fine with r354148 and reproduce the crash
R> with this revision applied.
R> 
R> Here is the relevant portion of my /etc/rc.conf:
R> 
R> # Lagg
R> ifconfig_em0="up"
R> wlans_iwn0="wlan0"
R> ifconfig_wlan0="WPA"
R> create_args_wlan0="wlanaddr 3c:97:0e:48:3f:f8 up"
R> cloned_interfaces="lagg0"
R> ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP"
R> ifconfig_lagg0_ipv6="inet6 accept_rtadv"
R> rtsold_enable="YES"
R> 
R> [1] https://imgur.com/a/lBtq3FW
R> -- 
R> Renato Botelho

-- 
Gleb Smirnoff

--qp4W5+cUSnZs0RIF
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="if_siocaddmulti.diff"

Index: sys/net/if.c
===================================================================
--- sys/net/if.c	(revision 354565)
+++ sys/net/if.c	(working copy)
@@ -3571,7 +3571,9 @@ if_siocaddmulti(void *arg, int pending)
 	if (pending > 1)
 		if_printf(ifp, "%d SIOCADDMULTI coalesced\n", pending);
 #endif
+	CURVNET_SET(ifp->if_vnet);
 	(void )(*ifp->if_ioctl)(ifp, SIOCADDMULTI, 0);
+	CURVNET_RESTORE();
 }
 
 /*

--qp4W5+cUSnZs0RIF--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191109041623.GS2195>