From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755031AbcBVNe1 (ORCPT ); Mon, 22 Feb 2016 08:34:27 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:17006 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754217AbcBVNe0 (ORCPT ); Mon, 22 Feb 2016 08:34:26 -0500 X-IronPort-AV: E=Sophos;i="5.22,484,1449532800"; d="scan'208";a="339923982" Subject: Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON To: "Gonglei (Arei)" , David Miller References: <1455931646-5672-1-git-send-email-arei.gonglei@huawei.com> <20160219.233643.95383657086552033.davem@davemloft.net> <33183CC9F5247A488A2544077AF19020B02E492F@SZXEMA503-MBS.china.huawei.com> CC: "netdev@vger.kernel.org" , "Huangpeng (Peter)" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" From: David Vrabel X-Enigmail-Draft-Status: N1110 Message-ID: <56CB0E3C.8080401@citrix.com> Date: Mon, 22 Feb 2016 13:33:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <33183CC9F5247A488A2544077AF19020B02E492F@SZXEMA503-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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