From patchwork Wed Apr 12 17:43:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sumit Semwal X-Patchwork-Id: 97334 Delivered-To: patch@linaro.org Received: by 10.140.109.52 with SMTP id k49csp374431qgf; Wed, 12 Apr 2017 10:44:43 -0700 (PDT) X-Received: by 10.98.204.155 with SMTP id j27mr16298299pfk.213.1492019083338; Wed, 12 Apr 2017 10:44:43 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l17si21057414pgj.292.2017.04.12.10.44.43; Wed, 12 Apr 2017 10:44:43 -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 S1754869AbdDLRoj (ORCPT + 6 others); Wed, 12 Apr 2017 13:44:39 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:33767 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755093AbdDLRoh (ORCPT ); Wed, 12 Apr 2017 13:44:37 -0400 Received: by mail-pg0-f52.google.com with SMTP id x125so18163164pgb.0 for ; Wed, 12 Apr 2017 10:44:37 -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=GGvw/2zrGpE+RoaIY2QmKo6BzsFTPo2LKKxN0xCGMek8yy5oPnVYMym2Dcged5rub0 omQTgUteFcAs6bA/VfAUlF45lGuhzgDZJrdLxH+4lqBNQKDrpwJHloFw+rhzqdaWyVFp Qf0pb9b0jIMqPgAAL/hlLItsqvpFU5v9SOqOI= 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=ZCSrJcUBRSab7XaMj2uUw7vsgOAnKuw5H1RELzkQ7NX44dftF75jfrBycJCaKw2A1Q nS82S9lUb6TGKlmBTDLvNqH7RKDr4F5grfR3Du4woOu21ATrxC5HjkRSdtZZayvIXWRa p/C8cmGJA4VGOalZ2iwU+z1IaKYvcD3WVvyyRKLcUE7a64NKoCWDWOKhYexf8HOMhehG XalviuOnoyBggqzqmIcQhE/RB7tJv5HwitzX6r1MIgzpxtGfy/O2vGNHJUba0aqp0WcX 4y7rRYUxmEtBE4vQXeCKC9tpU5Ml4Vo+OI2e18iS6vc2fw1F1+qJTHWrivF/n0aN0Xk9 9ONA== X-Gm-Message-State: AFeK/H1NcPBZl7C9+zCKuc9k3QrweXQnZTNGg63pC6mZingbd8BmW7kt5sirfu6tOlwM4kl5 X-Received: by 10.98.34.20 with SMTP id i20mr48214699pfi.102.1492019076487; Wed, 12 Apr 2017 10:44:36 -0700 (PDT) Received: from phantom.lan ([106.51.225.38]) by smtp.gmail.com with ESMTPSA id r17sm37750019pfa.13.2017.04.12.10.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Apr 2017 10:44:35 -0700 (PDT) From: Sumit Semwal To: stable@vger.kernel.org Cc: Vitaly Kuznetsov , "K . Y . Srinivasan" , Greg Kroah-Hartman , Sumit Semwal Subject: [v2 PATCH for-4.4 12/16] Drivers: hv: balloon: keep track of where ha_region starts Date: Wed, 12 Apr 2017 23:13:46 +0530 Message-Id: <1492019030-13567-13-git-send-email-sumit.semwal@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1492019030-13567-1-git-send-email-sumit.semwal@linaro.org> References: <1492019030-13567-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; }