Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1339474

Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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