All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Robertson <alanr@unix.sh>
To: vyasevic@redhat.com
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, davem@gavemloft.net,
	kuznet@ms2.inr.ac.ru
Subject: Re: [PATCH net] rtnetlink: ndo_dflt_fdb_del() never works
Date: Fri, 31 May 2013 13:59:07 -0600	[thread overview]
Message-ID: <51A9010B.6060307@unix.sh> (raw)
In-Reply-To: <51A8D9D3.3020601@redhat.com>

On 05/31/2013 11:11 AM, Vlad Yasevich wrote:
> On 05/31/2013 12:43 PM, Alan Robertson wrote:
>> On 05/31/2013 02:46 AM, David Miller wrote:
>>> From: Alan Robertson <alanr@unix.sh>
>>> Date: Thu, 30 May 2013 16:01:55 -0600
>>>
>>>> ndo_dflt_fdb_del is checking for a condition which is opposite that
>>>> which ndo_dflt_fdb_add enforces.  ndo_dflt_fdb_add declares an error
>>>> if (ndm->ndm_state && !(ndm->ndm_state) & NUD_PERMANENT)) - that
>>>> is, if the
>>>> entry is static.  This is consistent with the failure error message.
>>>>
>>>> On the other hand, ndo_dflt_del() declares an error
>>>> if (ndm_state & NUD_PERMANENT) - which is inconsistent with the add
>>>> precondition, and inconsistent with its failure message text.
>>>> As it is now, you can't delete any entry which add allows to be
>>>> added -
>>>> so entry deletion always fails.
>>>>
>>>> Signed-off-by: Alan Robertson <alanr@unix.sh>
>>> What about the ->ndm_state part of the add() test?  Why not include
>>> that in the del() check?
>> I had three different thoughts about this:
>>    1) Replicated the add check in the delete
>>    2) Do what I did - make it where you can only delete those really
>> marked as static
>>    3) Eliminate all delete checks
>>
>> The problem is -- I'm not sure why the ndm->ndm_state check is in there
>> -- I don't know how to make that condition occur.  It has the feel of a
>> check to be made before things are fully initialized - or maybe even
>> just leftover cruft.
>>
>
> 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.
>
>> You could make the argument that option (3) is the best -- if it's been
>> added successfully, you ought to be able to delete it.
>
> Hmm..  _del() always deletes and flags/states don't matter much
> generally.  I agree that the check isn't really needed as it isn't
> really protecting anything.

So is that what folks want me to do?

-- 
    Alan Robertson <alanr@unix.sh> - @OSSAlanR

"Openness is the foundation and preservative of friendship...  Let me claim from you at all times your undisguised opinions." - William Wilberforce

  reply	other threads:[~2013-05-31 19:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 22:01 [PATCH net] rtnetlink: ndo_dflt_fdb_del() never works Alan Robertson
2013-05-31  8:46 ` David Miller
2013-05-31 16:43   ` Alan Robertson
2013-05-31 17:11     ` Vlad Yasevich
2013-05-31 19:59       ` Alan Robertson [this message]
2013-05-31 23:42       ` David Miller
2013-06-03 21:40         ` Alan Robertson

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=51A9010B.6060307@unix.sh \
    --to=alanr@unix.sh \
    --cc=davem@davemloft.net \
    --cc=davem@gavemloft.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.com \
    /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.