From: Patrick McHardy <kaber@trash.net>
To: Wang Chen <wangchen@cn.fujitsu.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David S. Miller" <davem@davemloft.net>,
NETDEV <netdev@vger.kernel.org>,
davies@maniac.ultranet.com, grundler@parisc-linux.org,
kyle@parisc-linux.org
Subject: Re: [PATCH] net-driver: Drivers don't set IFF_* flag [Was: [PATCH 3/3] netdevice: order of synchronization of IFF_PROMISC and IFF_ALLMULTI]
Date: Mon, 23 Jun 2008 16:52:33 +0200 [thread overview]
Message-ID: <485FB8B1.8020000@trash.net> (raw)
In-Reply-To: <485FB6D1.7000604@cn.fujitsu.com>
Wang Chen wrote:
> Patrick McHardy said the following on 2008-6-23 21:47:
>>>>> @@ -5528,6 +5529,7 @@ de4x5_ioctl(struct net_device *dev, struct ifreq
>>>>> *rq, int cmd)
>>>>> omr &= ~OMR_PR;
>>>>> outl(omr, DE4X5_OMR);
>>>>> dev->flags &= ~IFF_PROMISC;
>>>>> + dev->promiscuity = 0;
>>>>> break;
>>>> Shouldn't this be using dev_set_promiscuity().
>>>>
>> I actually meant dev_change_flags(), sorry.
>>
>
> dev_change_flags() can not completely change flag IFF_PROMISC like
> IFF_UP, etc.
It shouldn't (in the case of IFF_PROMISC). It can for IFF_UP.
> So dev_change_flags() has no big difference to dev_set_promiscuity().
> I think dev_set_promiscuity() is suitable here.
It doesn't send notifications and this should always be
done if changes are performed on behalf of userspace.
>>> No.
>>> 1. dev_set_promiscuity do
>>> a. set/unset IFF_PROMISC
>>> b. promiscuity++/--
>>> c. audit
>>> d. dev_set_rx_mode (upload unicast and multicast list to device)
>>> Here, in ioctl, a & b is enough.
>> Auditing should certainly be done if promiscous mode is set.
>> Calling dev_set_rx_mode doesn't hurt, even if it does the ioctl
>> handler could be changed not to care. Besides this is neither
>> taking the rtnl_mutex as required nor sending notifcations
>> to userspace.
>>
>
> Agree.
>
>>> 2. dev->flags unset IFF_PROMISC and dev->promiscuity = 0 can not be
>>> replaced by dev_set_promiscuity(). Because, we don't decrease
>>> promiscuity here, but set promiscuity zero for unset IFF_PROMISC.
>> And that looks like a bug, the driver shouldn't disable
>> promiscuity if something still requires it.
>>
>
> It's hard to say that.
> In theory, user-space can require device to disable promisc by driver's
> ioctl.
It can't normally, only this driver can. And that doesn't
look right.
> But OTOH if something else still want device to be promisc, user and
> driver have no method to let them decrease the refcnt promiscuity. Because
> promiscuity decrement is initiative action from upper layer, drivers don't
> know who need promiscuity.
>
> Humm, tired, go to sleep and figure out how to do after refreshing. :)
I'd suggest to make it user dev_change_flags() and
maybe even print a warning and add these ioctls to
feature-removal-schedule.
next prev parent reply other threads:[~2008-06-23 14: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
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 [this message]
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=485FB8B1.8020000@trash.net \
--to=kaber@trash.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=davies@maniac.ultranet.com \
--cc=grundler@parisc-linux.org \
--cc=jgarzik@pobox.com \
--cc=kyle@parisc-linux.org \
--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.