[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHA+R7NJod_=R=Hh2Mz7nMiTxCMv=E4TMLsn2uOrS+f9gp+uHQ@mail.gmail.com>
Date: Tue, 28 Jul 2015 15:38:21 -0700
From: Cong Wang <cwang@...pensource.com>
To: Nikolay Aleksandrov <razor@...ckwall.org>
Cc: netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
"bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Cong Wang <amwang@...hat.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH net] bridge: mdb: fix delmdb state in the notification
On Tue, Jul 28, 2015 at 4:10 AM, Nikolay Aleksandrov
<razor@...ckwall.org> wrote:
> From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>
> Since mdb states were introduced when deleting an entry the state was
> left as it was set in the delete request from the user which leads to
> the following output when doing a monitor (for example):
> $ bridge mdb add dev br0 port eth3 grp 239.0.0.1 permanent
> (monitor) dev br0 port eth3 grp 239.0.0.1 permanent
> $ bridge mdb del dev br0 port eth3 grp 239.0.0.1 permanent
> (monitor) dev br0 port eth3 grp 239.0.0.1 temp
> ^^^
> Note the "temp" state in the delete notification which is wrong since
> the entry was permanent, the state in a delete is always reported as
> "temp" regardless of the real state of the entry.
>
Hmm?
I think it is iproute2 who forgets to set entry->state when deleting it?
} else if (strcmp(*argv, "permanent") == 0) {
if (cmd == RTM_NEWMDB)
entry.state |= MDB_PERMANENT;
Kernel simply returns what you pass to it.
Please fix iproute2.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists