Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1893765ybn; Thu, 26 Sep 2019 03:56:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqzKADF4uqbsIReoQ7Ah+6YS2HQ00RDRWDld1kWtyn+yjm6kk54ECOPnyrx8FNhzZlwqB55s X-Received: by 2002:a17:906:7ac6:: with SMTP id k6mr2378474ejo.243.1569495380300; Thu, 26 Sep 2019 03:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569495380; cv=none; d=google.com; s=arc-20160816; b=zaBiBmnO4CST5vW9IAkwhguB/PaIIiPCrImR2wM1thmhZA06ue9DExqoXWUE9sEsZc kq7jzV8mq+lRHGHPSDMbvJWlGFhQ5qBHSdnaeR9r510xkGRoPGDPmLR7xYDtMANsqSaq 6J7+96WJyCBRQ0t56iex58Mq2FL4xbntYIkAbNxPm/wlLRzP9SUND9yXceVFzQdk0LL2 UYWvyicNFTYyh6+Fgdrzhczwii03zcNWuRWjGNARV357l69OcFdh4AERExM3mUr0bG0w G6mCxFkUqVuZijuecNEFB0kWSlU0gR9x6mATwOy4qhKwGwFs3nWUJcYAxtgWUavtezIn Cqzg== 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 :message-id:date:subject:cc:to:from; bh=sq1qvokc+JW8bwU3qT0Zvy9KAxqcl4GYe9dQ4wkCWXg=; b=s6CU07N0YPko+KJ21PPdYvHcZU5KyW0cAiACkqkHGH3o7QK4EIfNfhNqSKO09qQxSk /+rrOLaMyt1xvGeizlLE5DB92U4FskKdGNuOMXOPBxe4Wlgoq24VA57pePOanVSDk9Sf gVNCodmemkHlchIANEqjioC4h1AlhcvGJQmLZqZZ0tpnKlJiQKQ7C3NIMLo+MZd7UDkc Wbqv19HjqpWXYY3TFIGIYhZNfvOfqzqWYanEYyX8zLAgyJjbsVt8+v2XBDy7FTOTKM1j ieefQum63gTkkaYSZTCaAc7h1BpsaA6h5x9v82hmMHs43fr2/q9nL7nohMIN+gow0fkw SCIA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10si1095787edx.168.2019.09.26.03.55.57; Thu, 26 Sep 2019 03:56:20 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437540AbfIYOjQ (ORCPT + 99 others); Wed, 25 Sep 2019 10:39:16 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:42919 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391511AbfIYOjQ (ORCPT ); Wed, 25 Sep 2019 10:39:16 -0400 Received: from 1.general.apw.uk.vpn ([10.172.192.78] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iD8Rl-00011e-A7; Wed, 25 Sep 2019 14:39:13 +0000 From: Andy Whitcroft To: linux-pm@vger.kernel.org Cc: "Rafael J. Wysocki" , Len Brown , Pavel Machek , Andy Whitcroft , Andrea Righi , linux-kernel@vger.kernel.org Subject: [PATCH 1/1] PM / hibernate: memory_bm_find_bit -- tighten node optimisation Date: Wed, 25 Sep 2019 15:39:12 +0100 Message-Id: <20190925143912.22593-1-apw@canonical.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When looking for a bit by number we make use of the cached result from the preceding lookup to speed up operation. Firstly we check if the requested pfn is within the cached zone and if not lookup the new zone. We then check if the offset for that pfn falls within the existing cached node. This happens regardless of whether the node is within the zone we are now scanning. With certain memory layouts it is possible for this to false trigger creating a temporary alias for the pfn to a different bit. This leads the hibernation code to free memory which it was never allocated with the expected fallout. Ensure the zone we are scanning matches the cached zone before considering the cached node. Deep thanks go to Andrea for many, many, many hours of hacking and testing that went into cornering this bug. Reported-by: Andrea Righi Tested-by: Andrea Righi Signed-off-by: Andy Whitcroft --- kernel/power/snapshot.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 83105874f255..26b9168321e7 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -734,8 +734,15 @@ static int memory_bm_find_bit(struct memory_bitmap *bm, unsigned long pfn, * We have found the zone. Now walk the radix tree to find the leaf node * for our PFN. */ + + /* + * If the zone we wish to scan is the the current zone and the + * pfn falls into the current node then we do not need to walk + * the tree. + */ node = bm->cur.node; - if (((pfn - zone->start_pfn) & ~BM_BLOCK_MASK) == bm->cur.node_pfn) + if (zone == bm->cur.zone && + ((pfn - zone->start_pfn) & ~BM_BLOCK_MASK) == bm->cur.node_pfn) goto node_found; node = zone->rtree; -- 2.20.1