From: David Vrabel <david.vrabel@citrix•com>
To: "Gonglei (Arei)" <arei.gonglei@huawei•com>,
David Miller <davem@davemloft•net>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Huangpeng (Peter)" <peter.huangpeng@huawei•com>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"xen-devel@lists•xenproject.org" <xen-devel@lists•xenproject.org>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON
Date: Mon, 22 Feb 2016 13:33:48 +0000 [thread overview]
Message-ID: <56CB0E3C.8080401@citrix.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020B02E492F@SZXEMA503-MBS.china.huawei.com>
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
next prev parent reply other threads:[~2016-02-22 13:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-20 1:27 [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON Gonglei
2016-02-20 4:36 ` David Miller
2016-02-20 6:00 ` Gonglei (Arei)
2016-02-22 13:33 ` David Vrabel [this message]
2016-02-20 15:50 ` Sergei Shtylyov
2016-02-22 14:10 ` [Xen-devel] " David Vrabel
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=56CB0E3C.8080401@citrix.com \
--to=david.vrabel@citrix$(echo .)com \
--cc=arei.gonglei@huawei$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=peter.huangpeng@huawei$(echo .)com \
--cc=xen-devel@lists$(echo .)xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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