From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Cong Wang <cwang@twopensource.com>,
Tommi Rantala <tt.rantala@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
trinity@vger.kernel.org, Dave Jones <davej@redhat.com>
Subject: Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
Date: Mon, 01 Sep 2014 21:22:28 +0200 [thread overview]
Message-ID: <1409599348.21965.6.camel@localhost> (raw)
In-Reply-To: <20140830105821.GB18155@kria>
Hi,
On Sa, 2014-08-30 at 12:58 +0200, Sabrina Dubroca wrote:
> 2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote:
> > Hi Sabrina,
> >
> > [...]
> >
> > Sorry, just had time to look at this.
> >
> > The reason is not to have list corruption but that the calls down to
> > ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists
> > are locked by addr_list_lock and that's why I think we never saw any
> > problems with that, but drivers expect rtnl locked for those calls.
> >
> > But this problem also affects multicast join, so patch seems incomplete
> > to me (and for that matter ssm multicast join, too).
> >
> > Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
> > to change dev_get_by_flags, but as this is the only user it sure is
> > possible. RCU locked version is just easier composeable, so I wouldn't
> > touch that if needed in future, just also take rcu lock as before.
> >
> > So just adding rtnl_lock add appropriate places seems to be ok to me,
> > but still need to review parts of the ssm code.
> >
> > Also we should move ASSERT_RTNL checks from addrconf_join_solict to
> > ipv6_dev_mc_inc/dec.
> >
> > Thanks,
> > Hannes
>
> Thanks for explaining.
>
> I had a look at what you suggested.
>
>
> So, for anycast, on top of the previous patch, we'd have:
>
> ---
> diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
> index 210183244689..61dd3046b804 100644
> --- a/net/ipv6/anycast.c
> +++ b/net/ipv6/anycast.c
> static void aca_put(struct ifacaddr6 *ac)
> @@ -233,6 +235,8 @@ int ipv6_dev_ac_inc(struct net_device *dev, const struct in6_addr *addr)
> struct rt6_info *rt;
> int err;
>
> + ASSERT_RTNL();
> +
> idev = in6_dev_get(dev);
>
> if (idev == NULL)
> @@ -302,6 +306,8 @@ int __ipv6_dev_ac_dec(struct inet6_dev *idev, const struct in6_addr *addr)
> {
> struct ifacaddr6 *aca, *prev_aca;
>
> + ASSERT_RTNL();
> +
> write_lock_bh(&idev->lock);
> prev_aca = NULL;
> for (aca = idev->ac_list; aca; aca = aca->aca_next) {
> @@ -336,6 +342,8 @@ static int ipv6_dev_ac_dec(struct net_device *dev, const struct in6_addr *addr)
> {
> struct inet6_dev *idev = __in6_dev_get(dev);
>
> + ASSERT_RTNL();
> +
> if (idev == NULL)
> return -ENODEV;
> return __ipv6_dev_ac_dec(idev, addr);
ASSERT_RTNL() still performs a runtime check. While those are not really
fast paths, I still think it is better to keep them to a minimum and
place them only at places where we know all code which needs to be
guarded passes by:
I would suggest to move ASSERT_RTNL to ipv6_dev_mc_inc and
__ipv6_dev_mc_dec and even remove the checks from addrconf_join_solict
and addrconf_leave_solict. Does that cover all code paths and makes
sense?
> ---
>
>
> And for multicast:
> - locking order in the patch below: rtnl -> rcu -> ipv6_sk_mc_lock
> - ipv6_sock_mc_join: maybe move all the _unlock()'s together at the end of the function
> - do we need to modify rcu_dereference_protected in ipv6_sock_mc_drop/ipv6_sock_mc_close
> - I had a look at the other codepaths that call ipv6_dev_mc_inc/dec
> - ipv6_mc_destroy_dev, dev_forward_change, ipv6_add_dev,
> addrconf_join_solict -- all take rtnl or already have an
> ASSERT_RTNL()
> - pndisc_destructor, called from pneigh_ifdown/pneigh_delete
> - pndisc_constructor, called from pneigh_lookup -- pneigh_lookup
> has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and
> ndisc_recv_na
> - (hope I didn't miss any callers)
>
> As far as I could see, apart maybe from pndisc_constructor, it seems
> okay, but I'd like to hear your comments.
The rest of the patch looks good.
Can you or Cong post a final patch with the adapted ac_join/drop
changes?
Thanks,
Hannes
next prev parent reply other threads:[~2014-09-01 19:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 15:26 RTNL: assertion failed at net/ipv6/addrconf.c (1699) Tommi Rantala
2014-08-29 16:17 ` Vlad Yasevich
2014-08-29 18:14 ` Cong Wang
2014-08-29 19:53 ` Sabrina Dubroca
2014-08-29 22:54 ` Cong Wang
2014-08-30 10:50 ` Sabrina Dubroca
2014-08-30 1:51 ` Hannes Frederic Sowa
2014-08-30 10:58 ` Sabrina Dubroca
2014-08-30 17:11 ` Sabrina Dubroca
2014-09-01 19:22 ` Hannes Frederic Sowa [this message]
2014-09-01 21:05 ` [PATCH] ipv6: fix rtnl locking in setsockopt for anycast and multicast Sabrina Dubroca
2014-09-01 22:26 ` Hannes Frederic Sowa
2014-09-02 8:29 ` [PATCH net v2] " Sabrina Dubroca
2014-09-02 10:07 ` Hannes Frederic Sowa
2014-09-02 16:43 ` Cong Wang
2014-09-05 18:53 ` David Miller
2014-09-05 18:58 ` Cong Wang
2014-09-05 19:12 ` Hannes Frederic Sowa
2014-09-05 19:23 ` Cong Wang
2014-09-05 19:25 ` David Miller
2014-09-05 19:34 ` Cong Wang
2014-09-05 19:21 ` David Miller
2014-09-02 16:50 ` RTNL: assertion failed at net/ipv6/addrconf.c (1699) Cong Wang
2014-09-02 17:58 ` Hannes Frederic Sowa
2014-09-02 18:04 ` Cong Wang
2014-09-02 18:11 ` Eric Dumazet
2014-09-02 18:15 ` Cong Wang
2014-09-02 18:21 ` Eric Dumazet
2014-09-02 18:37 ` Cong Wang
2014-09-02 19:08 ` Vlad Yasevich
2014-09-02 18:18 ` Hannes Frederic Sowa
2014-09-02 18:40 ` Cong Wang
2014-09-02 19:02 ` Hannes Frederic Sowa
2014-09-02 19:18 ` Cong Wang
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=1409599348.21965.6.camel@localhost \
--to=hannes@stressinduktion.org \
--cc=cwang@twopensource.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=trinity@vger.kernel.org \
--cc=tt.rantala@gmail.com \
--cc=yoshfuji@linux-ipv6.org \
/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.