From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78826C433ED for ; Tue, 13 Apr 2021 10:49:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 59049613BF for ; Tue, 13 Apr 2021 10:49:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343968AbhDMKtp (ORCPT ); Tue, 13 Apr 2021 06:49:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343891AbhDMKsr (ORCPT ); Tue, 13 Apr 2021 06:48:47 -0400 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [IPv6:2a05:d018:a4d:6403:2dda:8093:274f:d185]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45877C061574 for ; Tue, 13 Apr 2021 03:48:25 -0700 (PDT) Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:72b3:d5ff:feb1:e101]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 7678944263; Tue, 13 Apr 2021 10:48:21 +0000 (UTC) Subject: Re: xen-netback hotplug-status regression bug To: paul@xen.org, Wei Liu , xen-devel@lists.xenproject.org, netdev@vger.kernel.org, Paul Durrant References: From: Michael Brown Message-ID: <58ccc3b7-9ccb-b9bf-84e7-4a023ccb5c56@ipxe.org> Date: Tue, 13 Apr 2021 11:48:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 13/04/2021 08:12, Paul Durrant wrote: >> If the frontend subsequently disconnects and reconnects (e.g. >> transitions through Closed->Initialising->Connected) then: >> >> - Nothing recreates "hotplug-status" >> >> - When the frontend re-enters Connected state, connect() sets up a >> watch on "hotplug-status" again >> >> - The callback hotplug_status_changed() is never triggered, and so the >> backend device never transitions to Connected state. > > That's not how I read it. Given that "hotplug-status" is removed by the > call to hotplug_status_changed() then the next call to connect() should > fail to register the watch and 'have_hotplug_status_watch' should be 0. > Thus backend_switch_state() should not defer the transition to > XenbusStateConnected in any subsequent interaction with the frontend. Thank you for the reply. I've tested and confirmed my initial hypothesis: the call to xenbus_watch_pathfmt() succeeds even if the node does not exist. I confirmed this with ftrace using: cd /sys/kernel/debug/tracing echo function_graph > current_tracer echo set_backend_state > set_ftrace_filter echo xenbus_watch_pathfmt >> set_ftrace_filter echo register_xenbus_watch >> set_ftrace_filter echo xenbus_dev_fatal >> set_ftrace_filter On the second time that the frontend transitions to Connected, this produced the trace: set_backend_state [xen_netback]() { register_xenbus_watch(); register_xenbus_watch(); xenbus_watch_pathfmt() { register_xenbus_watch(); } } which seems to confirm that the error path in xenbus_watch_path() is *not* taken, i.e. that the call to register_xenbus_watch() succeeded even though the node did not exist. Other observations also seem to confirm this behaviour: - Running "xenstore ls" in dom0 confirms that on the second frontend transition to Connected, the frontend state is indeed Connected (4) but the backend state remains in InitWait (2) - Running "xenstore watch /local/domain/0/backend/vif//0/hotplug-status" *before* starting the domU confirms that it is possible to create a watch on a node that does not (yet) exist, and that the watch *is* notified when the node is later created. > Are you seeing the watch successfully re-registered even though the node > does not exist? Perhaps there has been a change in xenstore behaviour? So, the TL;DR is that yes, the watch does successfully register even though the node does not exist. From a quick look through the xenstored source, it looks as though the only check on the node name is the call to is_valid_nodename(), which seems to perform a syntactic validity check only. I can't immediately find any commit that would have changed this behaviour. Thanks, Michael