Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1339474
| From | David Vrabel <david.vrabel@citrix.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON |
| Date | 2016-02-22 14:40 +0100 |
| Message-ID | <r4YSu-6vs-5@gated-at.bofh.it> (permalink) |
| References | <r44wV-5K3-7@gated-at.bofh.it> <r47uN-7VV-3@gated-at.bofh.it> <r48TT-Dy-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 20/02/16 06:00, Gonglei (Arei) wrote: > Hi, > > Thanks for rapid feedback :) > >> From: David Miller [mailto:davem@davemloft.net] >> Sent: Saturday, February 20, 2016 12:37 PM >> >> From: Gonglei <arei.gonglei@huawei.com> >> Date: Sat, 20 Feb 2016 09:27:26 +0800 >> >>> It's possible for a race condition to exist between xennet_open() and >>> talk_to_netback(). After invoking netfront_probe() then other >>> threads or processes invoke xennet_open (such as NetworkManager) >>> immediately may trigger BUG_ON(). Besides, we also should reset >>> real_num_tx_queues in xennet_destroy_queues(). >> >> One should really never invoke register_netdev() until the device is >> %100 fully initialized. >> >> This means you cannot call register_netdev() until it is completely >> legal to invoke your ->open() method. >> >> And I think that is what the real problem is here. >> >> If you follow the correct rules for ordering wrt. register_netdev() >> there are no "races". Because ->open() must be legally invokable >> from the exact moment you call register_netdev(). >> > > Yes, I agree. Though that's the historic legacy problem. ;) > >> I'm not applying this, as it really sounds like the fundamental issue >> is the order in which the xen-netfront private data is initialized >> or setup before being registered. > > That means register_netdev() should be invoked after xennet_connect(), right? No. This would mean that the network device is removed and re-added when a guest is migrated which at best would result in considerably more downtime (e.g., the IP address has to be renegotiated with DHCP). David
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON Gonglei <arei.gonglei@huawei.com> - 2016-02-20 02:30 +0100
Re: [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON David Miller <davem@davemloft.net> - 2016-02-20 05:40 +0100
RE: [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON "Gonglei (Arei)" <arei.gonglei@huawei.com> - 2016-02-20 07:10 +0100
Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON David Vrabel <david.vrabel@citrix.com> - 2016-02-22 14:40 +0100
Re: [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-02-20 17:00 +0100
Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON David Vrabel <david.vrabel@citrix.com> - 2016-02-22 15:20 +0100
csiph-web