From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Date: Fri, 01 May 2015 09:45:55 -0700 Subject: [Intel-wired-lan] [PATCH 0/3] Stop using dev_kfree_skb_any in NAPI Tx clean-up In-Reply-To: <20150501.114223.1837223121502998313.davem@davemloft.net> References: <20150430205423.1512.13487.stgit@ahduyck-vm-fedora22> <20150501.114223.1837223121502998313.davem@davemloft.net> Message-ID: <5543ADC3.8010400@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On 05/01/2015 08:42 AM, David Miller wrote: > From: Alexander Duyck > Date: Thu, 30 Apr 2015 13:58:12 -0700 > >> This change replaces the call to dev_kfree_skb_any in several NAPI based Tx >> clean-up paths with dev_kfree_skb. Where I made the replacement the >> function appeared to always be in softirq context so we can avoid the >> unnecessary time spent determining if we are in a hardirq context or not. > It isn't always in softirq context. > > We can do a netconsole transmit from any context, and that code > can and will invoke ->poll(). I knew ndo_start_xmit was affected by that, I didn't realize that the napi poll routine was as well. > As Francois noted, netpoll_send_skb_on_dev() loops trying to transmit, > and if the TX does nto give NETDEV_TX_OK it will try to execute TX > reclaim by invoking ->poll(). > > It's hard to trigger this, but if you do... the dev_kfree_skb_any() > really is necessary. Ugh, if anything it points out that there are probably a number of bugs in the various drivers out there since I think there were assumptions made on both sides about how all the NAPI and netpoll stuff works. I'll probably be submitting fixes today for a number of drivers to address all the spots that have been missed and little things that need to be addressed. - Alex