From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934949AbcA0Wuh (ORCPT ); Wed, 27 Jan 2016 17:50:37 -0500 Received: from p3plsmtps2ded03.prod.phx3.secureserver.net ([208.109.80.60]:52706 "EHLO p3plsmtps2ded03.prod.phx3.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933995AbcA0Wuc (ORCPT ); Wed, 27 Jan 2016 17:50:32 -0500 x-originating-ip: 72.167.245.219 From: "K. Y. Srinivasan" To: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com Cc: "K. Y. Srinivasan" Subject: [PATCH 02/13] Drivers: hv: vmbus: avoid infinite loop in init_vp_index() Date: Wed, 27 Jan 2016 16:26:44 -0800 Message-Id: <1453940815-26096-2-git-send-email-kys@microsoft.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1453940815-26096-1-git-send-email-kys@microsoft.com> References: <1453940792-25878-1-git-send-email-kys@microsoft.com> <1453940815-26096-1-git-send-email-kys@microsoft.com> X-CMAE-Envelope: MS4wfJTplJlTBhoVCiv+Xhs85o051YQy8Aa3icnZpEbhSmhflVAahHhupOMk7pI7ZgoE6EQF9FYoXW087GitiVKxKN1y3AU76dqlQiSlR5LvyEu49Ik2b5yh aRb+dg3F1VnPUemZerUw1LS8hGE1/LCXwm4aIUKsfHTMuBZKKgSPKc4mfmQl6NQrIJz6ljy2mGKFkWmobGKBtnJrxKT+xw5i5DXPzXgA8t33l5F7ksAOI6CZ rXk2V7h1XAGBq+9H4udWkQJ0EM4dnUL/tBsJz6dw04NNJUQoVwEs/fP+hsoG2l+iLgB8+cwzE5TTKV8z+u6FzK1J7Ec4lC38b2ufZyccLXYUfRPqLPD8VZBX j9iYY13/IXKTc9D0UWWDERbySloH8WyA1SjLweeH0VnVJJhoWf55k6YaEM7uOgKcsEwD6tR/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vitaly Kuznetsov When we pick a CPU to use for a new subchannel we try find a non-used one on the appropriate NUMA node, we keep track of them with the primary->alloced_cpus_in_node mask. Under normal circumstances we don't run out of available CPUs but it is possible when we we don't initialize some cpus in Linux, e.g. when we boot with 'nr_cpus=' limitation. Avoid the infinite loop in init_vp_index() by checking that we still have non-used CPUs in the alloced_cpus_in_node mask and resetting it in case we don't. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel_mgmt.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 107d72f..af1d82e 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -549,6 +549,17 @@ static void init_vp_index(struct vmbus_channel *channel, u16 dev_type) cpumask_of_node(primary->numa_node)); cur_cpu = -1; + + /* + * Normally Hyper-V host doesn't create more subchannels than there + * are VCPUs on the node but it is possible when not all present VCPUs + * on the node are initialized by guest. Clear the alloced_cpus_in_node + * to start over. + */ + if (cpumask_equal(&primary->alloced_cpus_in_node, + cpumask_of_node(primary->numa_node))) + cpumask_clear(&primary->alloced_cpus_in_node); + while (true) { cur_cpu = cpumask_next(cur_cpu, &available_mask); if (cur_cpu >= nr_cpu_ids) { -- 1.7.4.1