From patchwork Thu Apr 20 07:38:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sumit Semwal X-Patchwork-Id: 97717 Delivered-To: patch@linaro.org Received: by 10.140.109.52 with SMTP id k49csp667487qgf; Thu, 20 Apr 2017 00:39:23 -0700 (PDT) X-Received: by 10.99.209.85 with SMTP id c21mr6685213pgj.147.1492673963541; Thu, 20 Apr 2017 00:39:23 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 203si1845905pgf.183.2017.04.20.00.39.22; Thu, 20 Apr 2017 00:39:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943103AbdDTHjK (ORCPT + 6 others); Thu, 20 Apr 2017 03:39:10 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:34463 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S943086AbdDTHjI (ORCPT ); Thu, 20 Apr 2017 03:39:08 -0400 Received: by mail-oi0-f44.google.com with SMTP id x184so38846103oia.1 for ; Thu, 20 Apr 2017 00:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=XvfGN4kuV2GaT9V0Hew0AdCq55FIICrp9Uuj/cDy4xQ=; b=DtdAN2joC7m76t5DahpmZGibOTA4ZMmKzQt2vqreRxsI6lmkzbMKlpUPsm7R4RN1TQ BIblDAs6rxyCn13787XAUJmJ9GQOaa+OWoJY5mnmJXC7bGtDJioHf//d/bBjujCiAkiy ucTQJVoQijFo2Wcpa47qa9nK6QrECJDTM20DY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=XvfGN4kuV2GaT9V0Hew0AdCq55FIICrp9Uuj/cDy4xQ=; b=AX2qnGcW0rnck8vf4AeF+ejwZjEDy9H3s3mgKkS7VvYy8JQMDkcl5ndD69T2VZ88C0 dJ1xyo84PII64eksqkmtnMpVz1M5b9U5+hg8UTLAAMP4vpTdqlPmxEzZ3OowiISjM18/ N1PJdXDfHNWLAZjQtf0plIzadLppTB8LsJwEE5ZlzqNgJh9yZ7v1IyWkGXMZ9wmaCWT6 e/Fyt9ZyFrb2Q9WOkPYeQVh8Z+0DXZbJQN7tYrnsiZeNbQeTuiw2ZmgsplIAtJoUitE9 lpErQPf7lGmrjQ7h9zLr+7pl1+NQVpuW1wtxIvIjCerr2zETaFSrcxTj3j59M19e4VDT O3uQ== X-Gm-Message-State: AN3rC/4x1FKpo26ZjdAqax6ta5scbii4UZijKQqglaCAQiCi3CS9mshR jD2IYJNp2ky1uRkU X-Received: by 10.84.138.131 with SMTP id 3mr8787622plp.167.1492673947529; Thu, 20 Apr 2017 00:39:07 -0700 (PDT) Received: from phantom.lan ([106.51.225.38]) by smtp.gmail.com with ESMTPSA id t2sm8497717pfl.34.2017.04.20.00.39.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Apr 2017 00:39:06 -0700 (PDT) From: Sumit Semwal To: stable@vger.kernel.org Cc: Vitaly Kuznetsov , "K . Y . Srinivasan" , Greg Kroah-Hartman , Sumit Semwal Subject: [v3 PATCH for-4.4 5/7] Drivers: hv: balloon: keep track of where ha_region starts Date: Thu, 20 Apr 2017 13:08:41 +0530 Message-Id: <1492673923-1352-6-git-send-email-sumit.semwal@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1492673923-1352-1-git-send-email-sumit.semwal@linaro.org> References: <1492673923-1352-1-git-send-email-sumit.semwal@linaro.org> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Vitaly Kuznetsov [ Upstream commit 7cf3b79ec85ee1a5bbaaf936bb1d050dc652983b ] Windows 2012 (non-R2) does not specify hot add region in hot add requests and the logic in hot_add_req() is trying to find a 128Mb-aligned region covering the request. It may also happen that host's requests are not 128Mb aligned and the created ha_region will start before the first specified PFN. We can't online these non-present pages but we don't remember the real start of the region. This is a regression introduced by the commit 5abbbb75d733 ("Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural"). While the idea of keeping the 'moving window' was wrong (as there is no guarantee that hot add requests come ordered) we should still keep track of covered_start_pfn. This is not a revert, the logic is different. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sumit Semwal --- drivers/hv/hv_balloon.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) -- 2.7.4 diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 43af913..1542d89 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -430,13 +430,14 @@ struct dm_info_msg { * currently hot added. We hot add in multiples of 128M * chunks; it is possible that we may not be able to bring * online all the pages in the region. The range - * covered_end_pfn defines the pages that can + * covered_start_pfn:covered_end_pfn defines the pages that can * be brough online. */ struct hv_hotadd_state { struct list_head list; unsigned long start_pfn; + unsigned long covered_start_pfn; unsigned long covered_end_pfn; unsigned long ha_end_pfn; unsigned long end_pfn; @@ -682,7 +683,8 @@ static void hv_online_page(struct page *pg) list_for_each(cur, &dm_device.ha_region_list) { has = list_entry(cur, struct hv_hotadd_state, list); - cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn); + cur_start_pgp = (unsigned long) + pfn_to_page(has->covered_start_pfn); cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn); if (((unsigned long)pg >= cur_start_pgp) && @@ -854,6 +856,7 @@ static unsigned long process_hot_add(unsigned long pg_start, list_add_tail(&ha_region->list, &dm_device.ha_region_list); ha_region->start_pfn = rg_start; ha_region->ha_end_pfn = rg_start; + ha_region->covered_start_pfn = pg_start; ha_region->covered_end_pfn = pg_start; ha_region->end_pfn = rg_start + rg_size; }