[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1409944376.5306.9.camel@localhost>
Date: Fri, 05 Sep 2014 21:12:56 +0200
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Cong Wang <cwang@...pensource.com>
Cc: David Miller <davem@...emloft.net>,
Sabrina Dubroca <sd@...asysnail.net>,
Tommi Rantala <tt.rantala@...il.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>,
netdev <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
trinity@...r.kernel.org, Dave Jones <davej@...hat.com>
Subject: Re: [PATCH net v2] ipv6: fix rtnl locking in setsockopt for anycast
and multicast
On Fr, 2014-09-05 at 11:58 -0700, Cong Wang wrote:
> On Fri, Sep 5, 2014 at 11:53 AM, David Miller <davem@...emloft.net> wrote:
> > From: Sabrina Dubroca <sd@...asysnail.net>
> > Date: Tue, 2 Sep 2014 10:29:29 +0200
> >
> >> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
> >> triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()
> >>
> >> ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to
> >> take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with
> >> ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
> >> calling ipv6_dev_mc_inc/dec.
> >>
> >> This patch moves ASSERT_RTNL() up a level in the call stack.
> >>
> >> Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>
> >> Signed-off-by: Sabrina Dubroca <sd@...asysnail.net>
> >> Reported-by: Tommi Rantala <tt.rantala@...il.com>
> >
> > Applied and queued up for -stable, thanks.
>
> I believe you applied a wrong version, at least the following
> is not correct:
>
> + if (!dev)
> + return -ENODEV;
>
> Sabrina took that from my draft patch, but they all don't
> realize this is wrong.
>
> (I did provide a correct version which is just ignored by you.)
What games are you playing? You know how patches are processed by David
and I even let him the choice by pointing out a problem in your patch so
that you could an update and send v2.
I really feel miffed about your behavior!
Anyway, I saw the hunk adding the return -ENODEV and didn't see any
problems with it. Sure it might be better if it would gone into a
separate patch. Can you elaborate what problems you see?
Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists