Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3334470imu; Sun, 11 Nov 2018 12:36:46 -0800 (PST) X-Google-Smtp-Source: AJdET5eS1gYgCdaAlnhOwA9q0/a+1mEEoHsmbiEiH51NNACnN0qpWMc6VeDqsxRyn8fz5aUtJkas X-Received: by 2002:a65:5a05:: with SMTP id y5-v6mr14987025pgs.161.1541968606514; Sun, 11 Nov 2018 12:36:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968606; cv=none; d=google.com; s=arc-20160816; b=eMqZ7zBgo/noJQyRBZdAlv4xVi5iR8X0Yk8jRYRThLadT2xaS2BqzN/m+V55i+UWqg AsnwnMEhblkwkj9Jlk7AgrqRCt3qz40r04mHQNWKF+7fAmK3iS0gBZFbvvpAmFS8oZrJ vPUk4JUKCwS11jlBuYY5Y82gSogK96bPpYeyb9NZXC7XT7IKtg9wp+GU87cbhtlc1WQs Tyfs9y1K03z+k+1PcFEJvNaqLOX13j0bAvCejIsPFheNaYnk7+CVBg01s3jlGx5xQ0OR SqIjmmdxEY6VNQ8Nsu2tPQkcuf5sxac3gzCYNkucqgnbdUX/leXLCcaX8xqrUgzPr1qM 688Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=XBO/Tx0Yurr5bJdpd0gtwdcKBS3x8Cph1P70moFqr+4=; b=d+/AHdMIA11Cxl0SbtQI9Ggz/ecevdFPU4IEoDO1H349USHGYHmbb78+SQ29YlkZuz SGcADKS75hx5qAIOxIWN0o/av+ZMnBxCjE6/oRqLIlrixbV9NqwuluKyxfttZ+fdWZjt F+eXdC2JVjw/2EiZJL1VYhVvbpv8Fy6dIpeKDIUlrm/+BJnX04+Zk37+qxMw6T21j+7O cVSylkDFhbYuxmTgpsMpHNitB3NXVN+Ushpgm9yaZyjsdCseKQaJl6TrR33pVP5btjjk MZk8g44Z+sMbex2WSFdWcz7ViMZtKjb6JiXvi7iPe1jWEdbyBD9QZ59pGO5tCcr9sz6M BfZg== 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 v9si13923440pgo.23.2018.11.11.12.36.31; Sun, 11 Nov 2018 12:36:46 -0800 (PST) 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 S1730174AbeKLFsM (ORCPT + 99 others); Mon, 12 Nov 2018 00:48:12 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49700 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730066AbeKLFsK (ORCPT ); Mon, 12 Nov 2018 00:48:10 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsW-0000l9-CQ; Sun, 11 Nov 2018 19:58:40 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsT-0001bI-8W; Sun, 11 Nov 2018 19:58:37 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David S. Miller" , "Boris Ostrovsky" , "Ross Lagerwall" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 170/366] xen-netfront: Improve error handling during initialization In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Ross Lagerwall commit e2e004acc7cbe3c531e752a270a74e95cde3ea48 upstream. This fixes a crash when running out of grant refs when creating many queues across many netdevs. * If creating queues fails (i.e. there are no grant refs available), call xenbus_dev_fatal() to ensure that the xenbus device is set to the closed state. * If no queues are created, don't call xennet_disconnect_backend as netdev->real_num_tx_queues will not have been set correctly. * If setup_netfront() fails, ensure that all the queues created are cleaned up, not just those that have been set up. * If any queues were set up and an error occurs, call xennet_destroy_queues() to clean up the napi context. * If any fatal error occurs, unregister and destroy the netdev to avoid leaving around a half setup network device. Signed-off-by: Ross Lagerwall Reviewed-by: Boris Ostrovsky Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/xen-netfront.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1879,27 +1879,19 @@ static int talk_to_netback(struct xenbus xennet_destroy_queues(info); err = xennet_create_queues(info, &num_queues); - if (err < 0) - goto destroy_ring; + if (err < 0) { + xenbus_dev_fatal(dev, err, "creating queues"); + kfree(info->queues); + info->queues = NULL; + goto out; + } /* Create shared ring, alloc event channel -- for each queue */ for (i = 0; i < num_queues; ++i) { queue = &info->queues[i]; err = setup_netfront(dev, queue, feature_split_evtchn); - if (err) { - /* setup_netfront() will tidy up the current - * queue on error, but we need to clean up - * those already allocated. - */ - if (i > 0) { - rtnl_lock(); - netif_set_real_num_tx_queues(info->netdev, i); - rtnl_unlock(); - goto destroy_ring; - } else { - goto out; - } - } + if (err) + goto destroy_ring; } again: @@ -1986,9 +1978,10 @@ abort_transaction_no_dev_fatal: xenbus_transaction_end(xbt, 1); destroy_ring: xennet_disconnect_backend(info); - kfree(info->queues); - info->queues = NULL; + xennet_destroy_queues(info); out: + unregister_netdev(info->netdev); + xennet_free_netdev(info->netdev); return err; }