Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp320529imm; Fri, 7 Sep 2018 23:05:16 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbE/B0vVnUXRwB3YVC8x+3FwPDX7UQYnbNRl1CI3wAB/OD6AztGrg1QXkyc2DA/q3sE3L7m X-Received: by 2002:a17:902:6907:: with SMTP id j7-v6mr11431838plk.323.1536386716701; Fri, 07 Sep 2018 23:05:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536386716; cv=none; d=google.com; s=arc-20160816; b=IaBwrfW/OVGxY7zau8jz8D0zlfxvLSp5QyjaCVrXPGluhORcF5fSBqk6lIXVxtLqMQ AI8ZM79XFB53ka+2CkK2Fi/AqhBqDl2GcoWbHIvpI0ksQKWQ4Fpl3vcksnrRzgb/DSZ/ VH9ibzC+iLAjMY7DDYwpw8lurZQvYhDKTf/iPvMuJbDja8kiAQF2ALqwDALwkRkZYLA8 0PmtQoIPmWEFZAUXRRMzRIdCmlvvctBcNEJy8muwWXF4VUg5MZYOJvHhmL8+YAYaj6B6 DozeULtvaiilVpG1zIDvn44z4VbkhlsD6ZVPS0CgjBuMSUa6Ps7azuMLlx2C3QEd7cjv Y7/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=k/bQh9hZHE9tRakBnPgxgyFMUjZjWLsJq07UQSJ+LI0=; b=zjt1sAemevC0oSWZYoDJ5X6VVLa2qXD3h9CvedFeyRlvbWZEqH4M7jYdM4yK/6w6J7 qBthvCkObdzxSgL4968lOfuvtLd1lxyBT3JRdUMZBEQ65RPDcJXI8JgoTrRu/ExvOF3o 56dneAcgEacK0UkpCvZRyaKocvX28VTYqkSi1srV9iQA2fWyApKxkEKQXQcD6l/E+ivx gdhCjJf39VGb16bBCrKF1uzfdrId53e0G2L7OIu1wccxGaMNOCZBfhNv4r58mYUd6RCv +gQDMk0yRNtCiUOITUqR+YBP7D6FtakKyOxx+0KYiN949Utj8U7N74aqjqGPnlU/DuHm RqDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z123-v6si11486736pfc.289.2018.09.07.23.04.58; Fri, 07 Sep 2018 23:05:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726343AbeIHKsW (ORCPT + 99 others); Sat, 8 Sep 2018 06:48:22 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:57318 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725734AbeIHKsV (ORCPT ); Sat, 8 Sep 2018 06:48:21 -0400 Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net [74.93.104.98]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 7F2821007FBED; Fri, 7 Sep 2018 23:03:49 -0700 (PDT) Date: Fri, 07 Sep 2018 23:03:48 -0700 (PDT) Message-Id: <20180907.230348.33221589667753465.davem@davemloft.net> To: jgross@suse.com Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, netdev@vger.kernel.org, boris.ostrovsky@oracle.com, stable@vger.kernel.org Subject: Re: [PATCH] xen/netfront: fix waiting for xenbus state change From: David Miller In-Reply-To: <20180907122130.30810-1-jgross@suse.com> References: <20180907122130.30810-1-jgross@suse.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 07 Sep 2018 23:03:49 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juergen Gross Date: Fri, 7 Sep 2018 14:21:30 +0200 > Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load > module manually") added a new wait queue to wait on for a state change > when the module is loaded manually. Unfortunately there is no wakeup > anywhere to stop that waiting. > > Instead of introducing a new wait queue rename the existing > module_unload_q to module_wq and use it for both purposes (loading and > unloading). > > As any state change of the backend might be intended to stop waiting > do the wake_up_all() in any case when netback_changed() is called. > > Fixes: 822fb18a82aba ("xen-netfront: wait xenbus state change when load module manually") > Cc: #4.18 > Signed-off-by: Juergen Gross Applied.