From mboxrd@z Thu Jan  1 00:00:00 1970
From: Florian Westphal <fw@strlen.de>
Subject: Re: kernel BUG in ipmr_queue_xmit()
Date: Fri, 30 Oct 2015 11:36:58 +0100
Message-ID: <20151030103658.GA25931@breakpoint.cc>
References: <alpine.OSX.2.00.1510291646320.59200@animac.local>
 <20151030001510.GG18062@breakpoint.cc>
 <alpine.OSX.2.00.1510291841480.68875@animac.local>
 <1446178542.6254.6.camel@edumazet-glaptop2.roam.corp.google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Ani Sinha <ani@arista.com>, Florian Westphal <fw@strlen.de>,
	netdev@vger.kernel.org, ani@anirban.org, fruggeri@arista.com
To: Eric Dumazet <eric.dumazet@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:33461 "EHLO
	Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1759573AbbJ3KhB (ORCPT
	<rfc822;netdev@vger.kernel.org>); Fri, 30 Oct 2015 06:37:01 -0400
Content-Disposition: inline
In-Reply-To: <1446178542.6254.6.camel@edumazet-glaptop2.roam.corp.google.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Signed-off-by: Ani Sinha <ani@arista.com>
> > ---
> >  net/ipv4/ipmr.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> > index 866ee89..48df3cc 100644
> > --- a/net/ipv4/ipmr.c
> > +++ b/net/ipv4/ipmr.c
> > @@ -936,7 +936,9 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
> >  
> >  			rtnl_unicast(skb, net, NETLINK_CB(skb).portid);
> >  		} else {
> > +			preempt_disable();
> >  			ip_mr_forward(net, mrt, skb, c, 0);
> > +			preempt_enable();
> >  		}
> >  	}
> >  }
> 
> I do not believe this fix is correct.

Yes, sorry.  I should have suggested local_bh_disable instead.

> Better replace the
> IP_INC_STATS_BH() by IP_INC_STATS()
>
> and IP_ADD_STATS_BH() by IP_ADD_STATS()

Hmm, whats the rationale for this?

Note that IP_ADD_STATS_BH in question is unconditional (not in
error path).  It seems that its virtually always called from softirq
except in the setsockopt case.

Thanks Eric.