From: Wengang <wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Cong Wang <cwang-xCSkyg8dI+0RB7SZvlqPiA@public.gmane.org>
Cc: netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] bonding: move ipoib_header_ops to vmlinux
Date: Tue, 30 Dec 2014 11:01:42 +0800 [thread overview]
Message-ID: <54A21596.7000706@oracle.com> (raw)
In-Reply-To: <CAHA+R7M-Nm_R-AaKQ0nX4L3O=BN5_m1v-8sWJSaE_UmGyo8zwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
于 2014年12月30日 05:32, Cong Wang 写道:
> On Mon, Nov 24, 2014 at 9:36 PM, Wengang Wang <wen.gang.wang@oracle.com> wrote:
>> When last slave of a bonding master is removed, the bonding then does not work.
>> At the time if packet_snd is called against with a master net_device, it calls
>> then header_ops->create which points to slave's header_ops. In case the slave
>> is ipoib and the module is unloaded, header_ops would point to invalid address.
>> Accessing it will cause problem.
>> This patch tries to fix this issue by moving ipoib_header_ops to vmlinux to keep
>> it valid even when ipoib module is unloaded.
>>
> I still don't think this is the right way to fix the bug, because
> there are other modules which have the same bug, for example,
> net/bluetooth/6lowpan.c (unless it can't be enslaved into a bond
> of course, I haven't verified). We don't want to move them all
> to builtin kernel, do we?
I don't think bluetooth needs bonding(and you didn't verify at all).
Do you have strong reason(examples)?
> On the other hand, as Jay explained, bonding is probably
> the only one which has the problem, why not solve it in bonding?
> I mean why do we have to adjust other modules just for bonding?
There are more than one way we do things. For this case, considering
needs, complexity and stability I think moving ipoib_header_ops is the
right way to go.
> When its slave device gets removed, some netdev event is sent
> to the master, so why not reset the header_ops to ether header ops
> up on this event? Something like below (not even compile tested):
>
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 184c434..aedccae 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1726,6 +1726,7 @@ static int __bond_release_one(struct net_device *bond_dev,
> if (!bond_has_slaves(bond)) {
> bond_set_carrier(bond);
> eth_hw_addr_random(bond_dev);
> + ether_setup(bond_dev);
> }
>
> unblock_netpoll_tx();
>
> It should solve more than just your ipoib case.
Do you think it's safe in a race condition? Before you change
header_ops, you have no
way to prevent another thread from accessing the old one.
> Last but not least, since you said you saw the crash in packet_snd(),
> it would also be interesting to know why packet_snd() still picks this
> bond dev after all its slaves are gone, after all it is not a functional
> device without any slave (its carrier is off).
It's quite normal in a race situation.
thanks,
wengang
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-12-30 3:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 5:36 [PATCH] bonding: move ipoib_header_ops to vmlinux Wengang Wang
[not found] ` <1416893768-21369-1-git-send-email-wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-11-25 6:07 ` David Miller
[not found] ` <20141125.010741.450666241983239119.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-11-25 7:19 ` Or Gerlitz
2014-11-25 7:19 ` Or Gerlitz
[not found] ` <54742D6E.9030605-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2014-11-25 18:41 ` Jay Vosburgh
2014-11-25 18:44 ` David Miller
[not found] ` <20141125.134450.1265438298771389292.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-11-26 1:30 ` Wengang
2014-12-03 1:50 ` Wengang Wang
[not found] ` <547E6C70.7040809-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-15 1:12 ` Wengang
2014-12-22 1:14 ` Wengang
2014-12-29 7:13 ` Wengang
[not found] ` <54A0FEA4.1080302@oracle.com>
[not found] ` <54A0FEA4.1080302-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-29 18:36 ` David Miller
2014-12-29 21:32 ` Cong Wang
[not found] ` <CAHA+R7M-Nm_R-AaKQ0nX4L3O=BN5_m1v-8sWJSaE_UmGyo8zwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-30 3:01 ` Wengang [this message]
[not found] ` <54A21596.7000706-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-30 4:25 ` David Miller
2014-12-30 8:26 ` Wengang
-- strict thread matches above, loose matches on Subject: below --
2014-12-30 3:04 Wengang Wang
[not found] ` <1419908682-17012-1-git-send-email-wen.gang.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-12-30 4:23 ` David Miller
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=54A21596.7000706@oracle.com \
--to=wen.gang.wang-qhclzuegtsvqt0dzr+alfa@public.gmane.org \
--cc=cwang-xCSkyg8dI+0RB7SZvlqPiA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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.