From patchwork Mon Oct 7 16:35:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrea Righi X-Patchwork-Id: 1172901 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46n5j22jytz9sPJ; Tue, 8 Oct 2019 03:36:38 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1iHVzt-00020k-JS; Mon, 07 Oct 2019 16:36:33 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iHVzr-0001zt-32 for kernel-team@lists.ubuntu.com; Mon, 07 Oct 2019 16:36:31 +0000 Received: from mail-wr1-f72.google.com ([209.85.221.72]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iHVzq-00056z-UU for kernel-team@lists.ubuntu.com; Mon, 07 Oct 2019 16:36:30 +0000 Received: by mail-wr1-f72.google.com with SMTP id t11so7773620wro.10 for ; Mon, 07 Oct 2019 09:36:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2cFpo1ZI2x59D9s76dwiuufaRBMAntbZorpfsNoB/8k=; b=XavKcXw7nWv7/GOP8nwKVMyBF3/O4MwleM6ebTHl9hzCaLtbacgE07/9g8lOMhsWoK +YwmyC6KMN244tp464DBcGWGV+1J3iYDfPwWfrM4NHu2ToJPp6vYcMiwJ5vjnLZBtzU2 bGrLNd/8GxKIyO0FhyHkwTVvzMweWp6HPgx4Kguuf2sgwSJOTdS2LILFdLpYqMasvvoS 3EP13ryD7e21gFgg8tXGrRtVltiADshG7CFrJNmTFqcrMYo0m6x+1bjBZ4vbZA/f6OPS Uuo/qG+uYhyftdw+03FWSQ/98K5/zNXF80xYTuLXNd5rlJf7ps9OKyyWzPyAa/ZnEwjJ AmBQ== X-Gm-Message-State: APjAAAV8pEBBcHaTtzGzruZgJiEJc3FWq6Q9rTpB6D67zyr02iMY+ft+ QG+EqB7+r4o7ve8GNETYgggWRbadWXWSh5Le2UdkUWRk+WC912IqjyAH1luiAJXO8M5S2ikCLi7 QVrk6aXEDMrP4QtLH1LKuYMDWvmHZB72PX1zO5KSpsg== X-Received: by 2002:a7b:c40c:: with SMTP id k12mr107561wmi.151.1570466190381; Mon, 07 Oct 2019 09:36:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqy+h69kNWToT5RXht68qCfKikcfPkWFSDYoLTaDkCTo4CVyNy5rExg+EnLKnMHpwSt6/dPk+w== X-Received: by 2002:a7b:c40c:: with SMTP id k12mr107544wmi.151.1570466190111; Mon, 07 Oct 2019 09:36:30 -0700 (PDT) Received: from localhost.localdomain ([95.239.130.49]) by smtp.gmail.com with ESMTPSA id x5sm13914545wrt.75.2019.10.07.09.36.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Oct 2019 09:36:29 -0700 (PDT) From: Andrea Righi To: kernel-team@lists.ubuntu.com Subject: [X] [PATCH 1/1] UBUNTU: SAUCE: PM / hibernate: memory_bm_find_bit -- tighten node optimisation Date: Mon, 7 Oct 2019 18:35:49 +0200 Message-Id: <20191007163550.20548-2-andrea.righi@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191007163550.20548-1-andrea.righi@canonical.com> References: <20191007163550.20548-1-andrea.righi@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Andy Whitcroft BugLink: https://bugs.launchpad.net/bugs/1847118 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 | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index f155c62..334191d 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -662,8 +662,14 @@ zone_found: * 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;