All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Bob Falken <NetFestivalHaveFun@gmx.com>,
	Julian Anastasov <ja@ssi.bg>,
	netdev@vger.kernel.org, kaber@trash.net, tgraf@suug.ch
Subject: Re: Multicast routing stops functioning after 4G multicast packets recived.
Date: Fri, 10 Jan 2014 08:43:25 +0100	[thread overview]
Message-ID: <20140110074325.GC17866@order.stressinduktion.org> (raw)
In-Reply-To: <1389339179.31367.98.camel@edumazet-glaptop2.roam.corp.google.com>

On Thu, Jan 09, 2014 at 11:32:59PM -0800, Eric Dumazet wrote:
> On Fri, 2014-01-10 at 08:10 +0100, Hannes Frederic Sowa wrote:
> > On Thu, Jan 09, 2014 at 11:01:46PM -0800, Eric Dumazet wrote:
> > > Its not clear to me why you expand ipmr_fib_lookup()
> > > 
> > > Is there something wrong with existing code ?
> > 
> > There are three users of ipmr_fib_lookup, two of them are in rcu_read_lock
> > section, one is not.
> > 
> > ipmr_fib_lookup does not pass down arg.rule reference, so I don't have a
> > chance to call fib_rule_put(arg.rule) on it. Thus I left ipmr_fib_lookup,
> > just adding FIB_LOOKUP_NOREF and expanding ipmr_fib_lookup into the
> > other function so I still have access to arg.rule to decrement the
> > reference counter.
> > 
> > Do you agree?
> 
> Hmm, I see the problem now.
> 
> What about adding a parameter to ipmr_fib_lookup(),
> to keep its spirit ?
> 
> ipmr_fib_lookup(net, &fl4, &mrt);
> ->
> ipmr_fib_lookup(net, &fl4, &mrt, &rule);
> 
> Since ipmr_rt_fib_lookup() has the same rule leak, no ?

No, ipmr_rt_fib_lookup is fine. This function gets called only from
rcu read locked section and we don't take table reference because of
FIB_LOOKUP_NOREF, so we don't need to put reference counter on arg.table.

We could add the additional argument, just ignoring it in ipmr_rt_fib_lookup.

> 
> Its a bit late here, so maybe following is just stupid :
> Cant we do the fib_rule_put() inside ipmr_fib_lookup() ?

We could add bool noref to ipmr_fib_lookup indicating we want to drop
reference to rule just after lookup.

I'll check if freeing a rule has additional side-effects on dependencies
in reg_vif_xmit. That would be a nice solution actually, thanks!

  reply	other threads:[~2014-01-10  7:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 20:14 Multicast routing stops functioning after 4G multicast packets recived Bob Falken
2014-01-10  6:36 ` Hannes Frederic Sowa
2014-01-10  7:01   ` Eric Dumazet
2014-01-10  7:10     ` Hannes Frederic Sowa
2014-01-10  7:32       ` Eric Dumazet
2014-01-10  7:43         ` Hannes Frederic Sowa [this message]
2014-01-10  7:50           ` Hannes Frederic Sowa
2014-01-12  7:42             ` Hannes Frederic Sowa
2014-01-13  0:56               ` Eric Dumazet
2014-01-13  1:45                 ` [PATCH net] net: avoid reference counter overflows on fib_rules in multicast forwarding Hannes Frederic Sowa
2014-01-13 15:18                   ` Eric Dumazet
2014-01-13 23:38                     ` Hannes Frederic Sowa
2014-01-15  1:40                   ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2014-01-12  0:25 Multicast routing stops functioning after 4G multicast packets recived Bob Falken
2014-01-07 17:01 Bob Falken
2014-01-07 17:43 ` Hannes Frederic Sowa
2014-01-07 20:11   ` Hannes Frederic Sowa
2014-01-07 20:20     ` Hannes Frederic Sowa
2014-01-07 20:26     ` Eric Dumazet
2014-01-07 20:29       ` Hannes Frederic Sowa
2014-01-04 18:53 Bob Falken
2013-12-21 22:35 Bob Falken
2014-01-03  7:37 ` Hannes Frederic Sowa
2013-12-19 16:28 Bob Falken
2013-12-19 17:24 ` Eric Dumazet
2013-12-19 17:32   ` Hannes Frederic Sowa
2013-12-22  3:10   ` Hannes Frederic Sowa
2013-12-19 14:48 Bob Falken
2013-12-19 15:09 ` Hannes Frederic Sowa
2013-12-19 15:15   ` Ben Greear
2013-12-19 15:48     ` Hannes Frederic Sowa
2014-01-04 19:55 ` Julian Anastasov
2014-01-04 23:38   ` Hannes Frederic Sowa
2014-01-05  8:56     ` Julian Anastasov
2014-01-05 10:41       ` Hannes Frederic Sowa
2014-01-05 19:12         ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140110074325.GC17866@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=NetFestivalHaveFun@gmx.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ja@ssi.bg \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.