From owner-svn-src-head@freebsd.org Tue May 9 20:39:20 2017 Return-Path: Delivered-To: svn-src-head@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 155B2D656C9 for ; Tue, 9 May 2017 20:39:20 +0000 (UTC) (envelope-from 0100015beeed2897-85c5b43b-da66-4c04-86ae-d4ebd3fd93e8-000000@amazonses.com) Received: from a8-237.smtp-out.amazonses.com (a8-237.smtp-out.amazonses.com [54.240.8.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CED85185 for ; Tue, 9 May 2017 20:39:19 +0000 (UTC) (envelope-from 0100015beeed2897-85c5b43b-da66-4c04-86ae-d4ebd3fd93e8-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1494362172; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=DnjoyBzGAjcvBemGuipj8e6EllRRfEYSCjaWuYMQTdM=; b=llg9OKvOcTYCnvubq4wIJBIc8oSUWnQn5o+BGzwa6NVVb1ZSenAmYUy4nNpL1jtS Y90XaKb+dfeUfNlSCR+JUVbwdeDsT11+unf+aPaLKQZzYpyyvUQUTnw8ammr7THwrJi BazFO+lryiPGBcooUW+yJH5ikLUXkpfPsParBZi8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1494362171; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=DnjoyBzGAjcvBemGuipj8e6EllRRfEYSCjaWuYMQTdM=; b=NFJcEiChxjUwORek4tWuzMTodW2gpdFAfg8C0aOmgMZsko76rkp+kmtyQaOmh2Fz 7Wyun0D1N01cZRkQLufPVmYw1JAZwlvK3NdB5o8TRb91Cf3uqa16+wlqd+ndW0+pB0X vQQJsWp+EVbXciBeBcR2tis3cYF70rujJVfI1dD8= Subject: Re: svn commit: r301198 - head/sys/dev/xen/netfront To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <201606021116.u52BGajD047287@repo.freebsd.org> <0100015bccba6abc-4c3b1487-25e3-4640-8221-885341ece829-000000@email.amazonses.com> <20170509100912.h3ylwugahvfi5cc2@dhcp-3-128.uk.xensource.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Colin Percival Message-ID: <0100015beeed2897-85c5b43b-da66-4c04-86ae-d4ebd3fd93e8-000000@email.amazonses.com> Date: Tue, 9 May 2017 20:36:11 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170509100912.h3ylwugahvfi5cc2@dhcp-3-128.uk.xensource.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2017.05.09-54.240.8.237 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Tue, 09 May 2017 20:39:20 -0000 On 05/09/17 03:09, Roger Pau Monn� wrote: > On Wed, May 03, 2017 at 05:13:40AM +0000, Colin Percival wrote: >> On 06/02/16 04:16, Roger Pau Monn� wrote: >>> Author: royger >>> Date: Thu Jun 2 11:16:35 2016 >>> New Revision: 301198 >>> URL: https://svnweb.freebsd.org/changeset/base/301198 >> >> I think this commit is responsible for panics I'm seeing in EC2 on T2 family >> instances. [...] >> but under high traffic volumes I think a separate thread can already be >> running in xn_rxeof, having dropped the RX lock while it passes a packet >> up the stack. This would result in two different threads trying to process >> the same set of responses from the ring, with (unsurprisingly) bad results. > > Hm, right, xn_rxeof drops the lock while pushing the packet up the stack. > There's a "XXX" comment on top of that, could you try to remove the lock > dripping and see what happens? > > I'm not sure there's any reason to drop the lock here, I very much doubt > if_input is going to sleep. Judging by $ grep -R -B 1 -A 1 if_input /usr/src/sys/dev I'm pretty sure that we do indeed need to drop the lock. If it's possible to enter if_input while holding locks, there are a *lot* of network interface drivers which are dropping locks unnecessarily... >> 3. Why xn_ifinit_locked is consuming ring responses. > > There might be pending RX packets on the ring, so netfront consumes them and > signals netback. In the unlikely event that the RX ring was full when > xn_ifinit_locked is called, not doing this would mean the RX queue would get > stuck forever, since there's no guarantee netfront will receive event channel > notifications. In that case, I'm guessing it would be safe to skip this if another thread is already running xn_rxeof and chewing through the packets on the ring? It would be easy to set a flag in xn_rxeof before we drop locks. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid