From patchwork Tue Nov 27 23:28:36 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 202319 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9B5222C0091 for ; Wed, 28 Nov 2012 10:29:01 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756208Ab2K0X2o (ORCPT ); Tue, 27 Nov 2012 18:28:44 -0500 Received: from merlin.infradead.org ([205.233.59.134]:47961 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755836Ab2K0X2m (ORCPT ); Tue, 27 Nov 2012 18:28:42 -0500 Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0]) by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1TdUZy-0004Kv-Oz; Tue, 27 Nov 2012 23:28:39 +0000 Message-ID: <1354058916.2534.25.camel@shinybook.infradead.org> Subject: [PATCH] br2684: don't send frames on not-ready vcc From: David Woodhouse To: chas williams - CONTRACTOR Cc: Krzysztof Mazur , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, nathan@traverse.com.au Date: Tue, 27 Nov 2012 23:28:36 +0000 In-Reply-To: <1354055783.2534.18.camel@shinybook.infradead.org> References: <1350926091-12642-1-git-send-email-krzysiek@podlesie.net> <1350926091-12642-3-git-send-email-krzysiek@podlesie.net> <1354036592.2534.6.camel@shinybook.infradead.org> <20121127173906.GA11390@shrek.podlesie.net> <1354039349.2534.11.camel@shinybook.infradead.org> <20121127135434.0728cd4f@thirdoffive.cmf.nrl.navy.mil> <1354055783.2534.18.camel@shinybook.infradead.org> X-Mailer: Evolution 3.6.1 (3.6.1-1.fc18) Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Avoid submitting patches to a vcc which is being closed. Things go badly wrong when the ->pop method gets later called after everything's been torn down. Signed-off-by: David Woodhouse Acked-by: Krzysztof Mazur --- On Tue, 2012-11-27 at 22:36 +0000, David Woodhouse wrote: > Nathan, does this help? I think that's necessary, but not sufficient. You'll want something like this too... I can now kill br2684ctl while there's a flood of outgoing packets, and get a handful of the printks that I had in here until a few seconds ago when I edited it out of the patch in my mail client... and no more panic. I do also now have Krzysztof's patch 1/7 (detach protocol before closing vcc) but I don't think it actually matters any more. --- a/net/atm/br2684.c~ 2012-11-23 23:14:29.000000000 +0000 +++ b/net/atm/br2684.c 2012-11-27 23:09:18.502403881 +0000 @@ -249,6 +249,12 @@ static int br2684_xmit_vcc(struct sk_buf skb_debug(skb); ATM_SKB(skb)->vcc = atmvcc = brvcc->atmvcc; + if (test_bit(ATM_VF_RELEASED, &atmvcc->flags) + || test_bit(ATM_VF_CLOSE, &atmvcc->flags) + || !test_bit(ATM_VF_READY, &atmvcc->flags)) { + dev_kfree_skb(skb); + return 0; + } pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, atmvcc, atmvcc->dev); atomic_add(skb->truesize, &sk_atm(atmvcc)->sk_wmem_alloc); ATM_SKB(skb)->atm_options = atmvcc->atm_options;