From: Wang Chen <wangchen@cn.fujitsu.com>
To: Joe Eykholt <jeykholt@cisco.com>
Cc: David Miller <davem@davemloft.net>,
jgarzik@pobox.com, netdev@vger.kernel.org, fubar@us.ibm.com,
kaber@trash.net
Subject: Re: [PATCH net-next 2/8] bonding: Check return of dev_set_promiscuity/allmulti
Date: Mon, 23 Jun 2008 09:36:06 +0800 [thread overview]
Message-ID: <485EFE06.7040104@cn.fujitsu.com> (raw)
In-Reply-To: <485D462E.3060003@cisco.com>
Joe Eykholt said the following on 2008-6-22 2:19:
> David Miller wrote:
>> From: Wang Chen <wangchen@cn.fujitsu.com>
>> Date: Fri, 20 Jun 2008 08:54:42 +0800
>>
>>> @@ -419,8 +419,11 @@ static void rlb_teach_disabled_mac_on_primary(struct bonding *bond, u8 addr[])
>>> }
>>>
>>> if (!bond->alb_info.primary_is_promisc) {
>>> - bond->alb_info.primary_is_promisc = 1;
>>> - dev_set_promiscuity(bond->curr_active_slave->dev, 1);
>>> + /* dev_set_promiscuity might overflow, check it here */
>>> + if (!dev_set_promiscuity(bond->curr_active_slave->dev, 1))
>> Like the first patch, please don't add such comments.
>>
>>> @@ -955,6 +965,9 @@ static void bond_mc_swap(struct bonding *bond, struct slave *new_active, struct
>>> }
>>>
>>> if (new_active) {
>>> + /* FIXME: promiscuity and allmulti might overflow,
>>> + * but bond_mc_swap's caller likes quiet handle.
>>> + */
>>> if (bond->dev->flags & IFF_PROMISC) {
>>> dev_set_promiscuity(new_active->dev, 1);
>>> }
>> Please reword this comment. The issue is that this code path has no
>> mechanism to signal errors upstream. It isn't about a specific type
>> of error condition in particular, it's about error handling capabilites
>> in general.
>
> If netdev->promiscuity overflows, shouldn't there be a WARN_ON or BUG_ON
> that catches that? Either someone forgot to clean up, or much less likely,
> the counter needs to be widened. It isn't necessarily the current caller's
> fault, but some indication of the problem is better than nothing.
>
If promiscuity overflows, dev_set_promiscuity will printk(KERN_WARNING) now.
Compare to that, WARN_ON has more information about modules info and dump stack.
But I think printk has enough information to indicate the problem and we
don't need WARN_ON.
How do you think?
next prev parent reply other threads:[~2008-06-23 1:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 0:54 [PATCH net-next 2/8] bonding: Check return of dev_set_promiscuity/allmulti Wang Chen
2008-06-20 2:07 ` David Miller
2008-06-20 2:56 ` Wang Chen
2008-06-21 18:19 ` Joe Eykholt
2008-06-23 1:36 ` Wang Chen [this message]
2008-06-23 3:55 ` Joe Eykholt
2008-06-23 11:13 ` Patrick McHardy
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=485EFE06.7040104@cn.fujitsu.com \
--to=wangchen@cn.fujitsu.com \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=jeykholt@cisco.com \
--cc=jgarzik@pobox.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).