Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756944Ab2K0Xvh (ORCPT ); Tue, 27 Nov 2012 18:51:37 -0500 Received: from shrek-wifi.podlesie.net ([93.179.225.50]:36554 "EHLO shrek.podlesie.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756773Ab2K0Xve (ORCPT ); Tue, 27 Nov 2012 18:51:34 -0500 Date: Wed, 28 Nov 2012 00:51:29 +0100 From: Krzysztof Mazur To: David Woodhouse Cc: chas williams - CONTRACTOR , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, nathan@traverse.com.au Subject: Re: [PATCH] br2684: don't send frames on not-ready vcc Message-ID: <20121127235129.GA20080@shrek.podlesie.net> 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> <1354058916.2534.25.camel@shinybook.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1354058916.2534.25.camel@shinybook.infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2055 Lines: 51 On Tue, Nov 27, 2012 at 11:28:36PM +0000, David Woodhouse wrote: > 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 > --- > 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. If you do this actually it's better to don't use patch 1/7 because it introduces race condition that you found earlier. > > --- 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; > With this patch you have still theoretical race that was fixed in patches 5 and 8 in pppoatm series, but I never seen that in practice. Acked-by: Krzysztof Mazur Krzysiek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/