From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: [PATCH net-next 2/2] 6lowpan: reassembly: fix kernel oops while unloading Date: Thu, 6 Mar 2014 14:38:51 +0100 Message-ID: <20140306133851.GC17526@breakpoint.cc> References: <1394052211-6976-1-git-send-email-alex.aring@gmail.com> <1394052211-6976-3-git-send-email-alex.aring@gmail.com> <20140305223246.GA17526@breakpoint.cc> <20140306060943.GB13676@omega> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Westphal , alex.bluesman.smirnov@gmail.com, dbaryshkov@gmail.com, netdev@vger.kernel.org To: Alexander Aring Return-path: Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:40061 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbaCFNix (ORCPT ); Thu, 6 Mar 2014 08:38:53 -0500 Content-Disposition: inline In-Reply-To: <20140306060943.GB13676@omega> Sender: netdev-owner@vger.kernel.org List-ID: Alexander Aring wrote: > On Wed, Mar 05, 2014 at 11:32:46PM +0100, Florian Westphal wrote: > > Alexander Aring wrote: > > > It seems that the inet_frag_queue is deleted but the timer is running. This > > > patch adds a for loop to iterate over all frag_queue entries in the > > > frag_bucket and calling del_timer for each frag_queue entry while > > > unloading the 6lowpan module. > > > > > > Signed-off-by: Alexander Aring > > > Reported-by: Phoebe Buckheister > > > --- > > > I am not sure about that I can do that in this simply way without hold > > > any lock of the inet_frag_queue or inet_frag_bucket. Please help there. > > > The kernel oops never occurs afterwards, but this isn't simple to test. > > > I can't test all cases. > > > > I find it hard to believe that this is a 6lowpan specific problem, > > most likely this needs a fix in inet_fragment code. > > > I thought that too, maybe it's a problem in the inet_fragment code. > > > There are two function which I call on exit: > > inet_frags_fini(&lowpan_frags); - which deletes the secret_timer. > inet_frags_exit_net(&net->ieee802154_lowpan.frags, &lowpan_frags); > - which runs a force inet_frag_evictor > > maybe I forgot to call some other function to cleanup the fragmentation. No, it looks correct. > I don't saw any other exit function and I do a similar cleanup like ipv4/ipv6 > and they don't have a module_exit function which is called for the > inet_fragment code. net/ipv6/netfilter/nf_defrag_ipv6_hooks.c has one (calls nf_ct_frag6_cleanup). I am currently testing this fix: diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c index 322dceb..3b01959 100644 --- a/net/ipv4/inet_fragment.c +++ b/net/ipv4/inet_fragment.c @@ -208,7 +208,7 @@ int inet_frag_evictor(struct netns_frags *nf, struct inet_frags *f, bool force) } work = frag_mem_limit(nf) - nf->low_thresh; - while (work > 0) { + while (work > 0 || force) { frag_mem_limit() may be inaccurate which causes evictor to terminate earlier than it should.