[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <51AD0D5B.1010001@unix.sh>
Date: Mon, 03 Jun 2013 15:40:43 -0600
From: Alan Robertson <alanr@...x.sh>
To: vyasevic@...hat.com
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
davem@...emloft.net, kuznet@....inr.ac.ru
Subject: Re: [PATCH net] rtnetlink: ndo_dflt_fdb_del() never works
I'd like to fix this problem - but it seems good to answer David
Miller's question before we decide which way to go. I certainly don't
know the answer...
I can do (1) and (2), but I'm not sure how to do (3) properly.
Vlad: Can you help out here?
On 05/31/2013 05:42 PM, David Miller wrote:
> From: Vlad Yasevich <vyasevic@...hat.com>
> Date: Fri, 31 May 2013 13:11:47 -0400
>
<snip>
>> The test is there to support simultaneous master and self
>> operations. The operation on a master may not always require a
>> NUD_PERMANENT state (ex: bridge) and we don't want to perform self
>> operations in that instance.
> I still don't understand the ndm_state check. Please use different
> words to explain it so that even an idiot like me can understand.
>
> Once we define what the check should exactly be I propose:
>
> 1) Keeping the check only in add()
>
> 2) Removing the state checks completely in del()
>
> 3) Validating at netdevice registry time or elsewhere that these
> default fdb ops are always used together. That wraps up everything
> to ensure that only doing the check in add() is provably correct.
> --
> 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
--
Alan Robertson <alanr@...x.sh> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce
--
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