From owner-svn-src-head@freebsd.org Sat Nov 9 04:16:26 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8572117CAAD; Sat, 9 Nov 2019 04:16:26 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4793jk14jjz4JxZ; Sat, 9 Nov 2019 04:16:25 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id xA94GNIK068522 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Nov 2019 20:16:23 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id xA94GNGo068521; Fri, 8 Nov 2019 20:16:23 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 8 Nov 2019 20:16:23 -0800 From: Gleb Smirnoff To: Renato Botelho 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> References: <201910291736.x9THa6Gd018030@repo.freebsd.org> <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="qp4W5+cUSnZs0RIF" Content-Disposition: inline In-Reply-To: <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 4793jk14jjz4JxZ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2019 04:16:26 -0000 --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--