From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: [PATCH 0/3] netpoll: Freeing skbs in hard irq context Date: Thu, 27 Mar 2014 18:14:36 -0700 Message-ID: <87mwgbkttv.fsf_-_@x220.int.ebiederm.org> References: <20140314.225923.61318448733570839.davem@davemloft.net> <87k3bwqgf7.fsf@xmission.com> <877g7wqg8e.fsf_-_@xmission.com> <20140317.154916.2276987764507311378.davem@davemloft.net> <87iorcgh5d.fsf_-_@xmission.com> <87fvmgf2c7.fsf_-_@xmission.com> <1395149407.22343.8.camel@deadeye.wl.decadent.org.uk> <87lhw7inzg.fsf@nemi.mork.no> <1395156229.9114.35.camel@edumazet-glaptop2.roam.corp.google.com> <2c96faab-4293-4e7f-b8e0-4997af745fbf@email.android.com> <063D6719AE5E284EB5DD2968C1650D6D0F6E02DB@AcuExch.aculab.com> Mime-Version: 1.0 Content-Type: text/plain Cc: =?utf-8?Q?'Bj=C3=B8rn?= Mork' , Eric Dumazet , Ben Hutchings , "stephen\@networkplumber.org" , "netdev\@vger.kernel.org" , "xiyou.wangcong\@gmail.com" , "mpm\@selenic.com" , "satyam.sharma\@gmail.com" , David Laight To: David Miller Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]:42194 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757008AbaC1BOt (ORCPT ); Thu, 27 Mar 2014 21:14:49 -0400 In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6E02DB@AcuExch.aculab.com> (David Laight's message of "Tue, 18 Mar 2014 15:52:37 +0000") Sender: netdev-owner@vger.kernel.org List-ID: In some case such as trigger_all_cpu_backtrace netpoll can wind up generating a lot of packets in hard irq context. My rough estimate is perhaps 1500 packets. That is larger than any driver tx ring, which makes netpoll_poll_dev necessary to transmit all of the netconsole packets immediately. Those 1500+ packets can take up a couple megabytes of memory if we aren't careful. On some machines that is enough to start depleting the polls GFP_ATOMIC can dig into, so netpoll needs to at a minimum to be able to reuse the memory for the skbs it has transmitted. Today this reclamation of transmitted packets happens in zap_completetion_queue as dev_kfree_skb_irq places all packets to be freed on a completion queue. netpoll then searches this queue for packets it thinks are freeable, and frees them. Unfortunately the current logic netpoll uses to decided a packet is freeable is incorrect and thus unsafe :( The logic netpoll uses to determine if a packet is freeable is to verify a skb does not have a destructor. Which works most of the time. But in pathological cases it can report that is a packet is freeable in hard irq context when it is not. This set of changes adds a function skb_irq_freeable and uses that function in zap_completion_queue to remove the bug, and in bowls of kfree_skb in skb_release_head_state to warn if we are inappropriate freeing a skb. While I don't expect this will allow anything except skbs sent by netpoll to be freed, solving the general problem rather than solving this for just packets generated by netpoll seems like a robust way of handling this. Eric W. Biederman (3): net: Add a test to see if a skb is freeable in irq context netpoll: Use skb_irq_freeable to make zap_completion_queue safe. net: Warn when a skb is freed inappropriately in hard irq context. include/linux/skbuff.h | 13 +++++++++++++ net/core/netpoll.c | 2 +- net/core/skbuff.c | 6 +++--- 3 files changed, 17 insertions(+), 4 deletions(-) Eric