From: Cong Wang <amwang@redhat.com>
To: Neil Horman <nhorman@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jiri Pirko <jpirko@redhat.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Herbert Xu <herbert@gondor.hengli.com.au>,
bonding-devel@lists.sourceforge.net,
Jay Vosburgh <fubar@us.ibm.com>,
Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: [v3 PATCH 1/2] bonding: sync netpoll code with bridge
Date: Thu, 09 Dec 2010 15:33:23 +0800 [thread overview]
Message-ID: <4D008643.5040500@redhat.com> (raw)
In-Reply-To: <20101208135746.GD11454@hmsreliant.think-freely.org>
On 12/08/10 21:57, Neil Horman wrote:
> On Wed, Dec 08, 2010 at 02:52:08AM -0500, Amerigo Wang wrote:
>> - bond_for_each_slave(bond, slave, i) {
>> - if ((slave->dev->priv_flags& IFF_DISABLE_NETPOLL) ||
>> - !slave->dev->netdev_ops->ndo_poll_controller)
>> - ret = false;
>> + np = kmalloc(sizeof(*np), GFP_KERNEL);
>> + err = -ENOMEM;
>> + if (!np)
>> + goto out;
>> +
>> + np->dev = slave->dev;
>> + err = __netpoll_setup(np);
> Setting up our own netpoll instance on each slave worries me a bit. The
> implication here is that, by doing so, some frames will get entirely processed
> by the slave. Most notably arp frames. That means anything that gets queued up
> to the arp_tx queue in __netpoll_rx will get processed during that poll event,
> and responded to with the mac of the slave device, rather than with the mac of
> the bond device, which isn't always what you want. I think if you go with this
> route, you'll need to add code to netpoll_poll_dev, right before the call to
> service_arp_queue, to check if IFF_SLAVE is set in priv_flags, and move the list
> to the master device, or some such.
Good point! Will fix it.
>
> It also seems like you'll want to zero out the other fields in the netpoll
> structure. Leaving garbage in them will be bad. Most notably here I'm looking
> at the rx_hook field. If its non-null we're going to add a bogus pointer to the
> rx_np list and call off into space at some point.
>
Ouch! I remember I really used kzalloc() here, don't know
why kmalloc() gets into the final patch. Odd, I need to double check
the patch. :-/
<...>
>> +static void __bond_netpoll_cleanup(struct bonding *bond)
>> +{
>> struct slave *slave;
>> int i;
>>
>> - bond_for_each_slave(bond, slave, i) {
>> - if (slave->dev&& IS_UP(slave->dev))
>> - netpoll_poll_dev(slave->dev);
>> - }
>> + bond_for_each_slave(bond, slave, i)
>> + if (slave->dev)
> Why are you checking slave->dev here? If the dev pointer has been set to NULL
> here it would seem we're not holding on to dev long enough. If we enabled
> netpoll with a dev pointer and lost it somewhere along the way, we're going to
> leak that struct netpoll memory that we allocated.
>
Hmm, seems you are right, read_lock should guarantee every slave on the list
has the right ->dev... But I think I should keep that IS_UP() checking...
<...>
>>
>> /* close slave before restoring its mac address */
>> dev_close(slave_dev);
>> @@ -2061,6 +2098,7 @@ static int bond_release_and_destroy(struct net_device *bond_dev,
>>
>> ret = bond_release(bond_dev, slave_dev);
>> if ((ret == 0)&& (bond->slave_cnt == 0)) {
>> + bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
> Why are you setting IFF_DISABLE_NETPOLL here? That seems unnecessecary
>
It gets removed in patch 2/2. :)
Thanks for review!
next prev parent reply other threads:[~2010-12-09 7:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 7:52 [v3 PATCH 1/2] bonding: sync netpoll code with bridge Amerigo Wang
2010-12-08 7:52 ` [v3 PATCH 2/2] netpoll: remove IFF_IN_NETPOLL flag Amerigo Wang
2010-12-08 8:16 ` Changli Gao
2010-12-08 8:36 ` Cong Wang
2010-12-08 8:49 ` Changli Gao
2010-12-08 8:52 ` Cong Wang
2010-12-08 13:57 ` [v3 PATCH 1/2] bonding: sync netpoll code with bridge Neil Horman
2010-12-09 7:33 ` Cong Wang [this message]
2010-12-09 7:40 ` Cong Wang
2010-12-15 10:52 ` Cong Wang
2010-12-15 11:59 ` Neil Horman
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=4D008643.5040500@redhat.com \
--to=amwang@redhat.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=fubar@us.ibm.com \
--cc=herbert@gondor.hengli.com.au \
--cc=jpirko@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=shemminger@vyatta.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.