All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Wang Chen <wangchen@cn.fujitsu.com>
Cc: Patrick McHardy <kaber@trash.net>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	NETDEV <netdev@vger.kernel.org>
Subject: Re: [PATCH 3/3] netdevice: order of synchronization of IFF_PROMISC and IFF_ALLMULTI
Date: Tue, 17 Jun 2008 22:52:04 -0400	[thread overview]
Message-ID: <48587854.8050400@pobox.com> (raw)
In-Reply-To: <48587295.40705@cn.fujitsu.com>

Wang Chen wrote:
> Patrick McHardy said the following on 2008-6-17 21:06:
>> Wang Chen wrote:
>>> Patrick McHardy said the following on 2008-6-16 18:03:
>>>> Wang Chen wrote:
>>>>> And about the comment, I copy it from dev_change_flags() and think
>>>>> it seems suit for here.
>>>>> Did I misunderstand this comment?
>>>> I think it refers to broken behaviour by drivers that set
>>>> IFF_PROMISC themselves when asked to disable multicast
>>>> filtering by setting IFF_ALLMULTI. This would cause the
>>>> test for changed flags in dev_set_promiscuity to return zero
>>>> and not program the device for promiscous mode properly.
>>>>
>>> Do you mean things like that in do_mc32_set_multicast_list()?
>> Yes.
>>
>>>> There are a few examples of this in the tree. But calling
>>>> dev_set_promiscuity() before dev_set_allmulti() only helps
>>>> in the dev_change_flags() case since its the only function
>>>> that might change both flags at once. In all other cases it
>>>> depends on the caller.
>>>>
>>>> So for the dev_change_flags() case VLAN already uses the
>>>> "proper" ordering, the other cases might be broken with
>>>> or without your patch.
>>>>
>>> Is there any other case might be broken?
>> If that ordering is really required, yes:
>>
>> - ip link set dev eth0 allmulticast on
>>
>> <sets allmulticast *and* promisous with broken driver>
>>
>> - ip link set dev eth0 promisc on
>>
>> <no change>
>>
>> So the only thing fixed by this workaround is of both are
>> enabled in a single command - something that doesn't even
>> make much sense since promisc will receive all multicast
>> frames anyway.
>>
>>>> I'd suggest to fix the drivers instead, perhaps start by
>>>> adding a warning to dev_change_flags() that is triggered
>>>> by the driver changing the flags itself.
>>>>
>>> In some driver's code of *_set_multicast_list(), IFF_PROMISC
>>> will be set if IFF_ALLMULTI is set.
>>> And there is comment about the necessity for setting IFF_PROMISC.
>>> /*
>>>  *    We must make the kernel realise we had to move
>>>  *    into promisc mode or we start all out war on
>>>  *    the cable. If it was a promisc request the
>>>  *    flag is already set. If not we assert it.
>>>  */
>>> So, I doubt about fixing the drivers.
>>
>> I have no idea what this comment is trying to say. Drivers
>> shouldn't change dev->flags.
>>
> 
> Yes.
> Maybe we should ask the authors about why they let driver to
> change the dev->flags.
> Fox example, about 3c527.
> Alan,
> Can you explain why do_mc32_set_multicast_list() change flag
> to IFF_PROMISC when IFF_ALLMULTI is set?
> 
> Jeff,
> Any suggestion about this?
> netdevice uses promiscuity as refcnt, and if driver set IFF_PROMISC
> but don't change promiscuity will break the refcnt.

Drivers should not be setting IFF_* flags in set_multicast_list().

The normal logic is that a driver interprets the request implied in 
set_multicast_list ("promisc, all-multi, or select multi?"), and then 
programs the hardware based on that.

On some hardware, IFF_ALLMULTI requires that the hardware receive all 
packets (promisc).  Even for that case, the driver should -not- be 
setting the IFF_PROMISC flag.  It should be aware of its own hardware 
programming state through some other method.

	Jeff





  reply	other threads:[~2008-06-18  2:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16  9:17 [PATCH 3/3] netdevice: order of synchronization of IFF_PROMISC and IFF_ALLMULTI Wang Chen
2008-06-16  9:27 ` Patrick McHardy
2008-06-16  9:39   ` Wang Chen
2008-06-16 10:03     ` Patrick McHardy
2008-06-17  1:42       ` Wang Chen
2008-06-17 13:06         ` Patrick McHardy
2008-06-18  2:27           ` Wang Chen
2008-06-18  2:52             ` Jeff Garzik [this message]
2008-06-18  3:22               ` Wang Chen
2008-06-20 15:07               ` [PATCH] net-driver: Drivers don't set IFF_* flag [Was: [PATCH 3/3] netdevice: order of synchronization of IFF_PROMISC and IFF_ALLMULTI] Wang Chen
2008-06-23 11:04                 ` Patrick McHardy
2008-06-23 13:33                   ` Wang Chen
2008-06-23 13:47                     ` Patrick McHardy
2008-06-23 14:44                       ` Wang Chen
2008-06-23 14:52                         ` Patrick McHardy
2008-06-24  1:02                           ` Wang Chen
2008-06-24  5:10                             ` Grant Grundler
2008-06-24  5:39                               ` Wang Chen
2008-06-27  1:14                                 ` v2 [PATCH 2/2] de4x5: Remove developer debug feature about set/clear promisc Wang Chen
2008-06-28 17:52                                   ` Grant Grundler
2008-06-30  3:24                                     ` v3 " Wang Chen
2008-07-02  4:22                                       ` Grant Grundler
2008-06-27  1:14                 ` v2 [PATCH 1/2] net-driver: Drivers don't set IFF_* flag Wang Chen

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=48587854.8050400@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=wangchen@cn.fujitsu.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.