Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp384035ybv; Wed, 19 Feb 2020 23:53:15 -0800 (PST) X-Google-Smtp-Source: APXvYqxxW9fZIIRjGkRpNi/tiMFD0PJnwaLxIPshZfNsSa387yHkJhKO7pwlykNvIMIqU90i7+Hy X-Received: by 2002:a9d:1c96:: with SMTP id l22mr23028174ota.322.1582185195612; Wed, 19 Feb 2020 23:53:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582185195; cv=none; d=google.com; s=arc-20160816; b=o+X1qHd8i54m2mRVW1ZqpCmDkT4j+rHg65/vxhIOQjK45ksfqSv45B11cexSA2FOAf KwFR6TaJF1sf6DXHFMRTrbfOtRZDLwEFjPckKfM/6OsQNqhE3j9esnrac8qBrnn2RwWT kwb9Runk+UJi5vCFpLAWQWt0DxD/jTOp0Ex6Ft9vmRv8yn/XxKJ6sRAP/8mdvAYPGstj du/6z2kuui/5Cc+XicmM+atHCMSickPg8nuXIbro6VmcDSKgg9Fi7d01414g1TrBuK2l Bm55KooIHM0UB5aV/WHw39jzhgC+mT8+KyxKoRAq1VeY6D9xwa90k+8hNEAXkthB7FRH 0qVg== 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=J97z2srl4Wee5Jlr8pg6slYnrBSkC2ldno/tGrtjVxc=; b=PI/dHLcyzHzmjG+pqX/PvcP8zvd8LbAhMzUMQ4ZsEVY99ZPPYjhOzVevFyDSC7G0F/ lUzfx7NyNw+78ZSi2d3nZF302Xqtl5zjdVtDkLyJ9PQMECKETah1WYB7n74cFtluTGY3 LP/rS3bjqdfS49SvinK2hfic7j8ji1kwiJis3xqU4KeO2h+Q1jQmwRF0ecoIj4Dl84+3 4hpasi1xK8m/+gGnKmqL/B3PdlBDndi5hXr001JcJ8BRStfn8K4+4lfHl4X9aiGR9Iit y9A0VE3OxUP7xTithJxJQ0BN63Yn4FRRFTb/SqMhUaRE54pJN2TfQCpnYQ4SIyJWYTrX aaPg== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v23si1226552oto.81.2020.02.19.23.53.03; Wed, 19 Feb 2020 23:53:15 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727034AbgBTHwg (ORCPT + 99 others); Thu, 20 Feb 2020 02:52:36 -0500 Received: from mga02.intel.com ([134.134.136.20]:57481 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726248AbgBTHwg (ORCPT ); Thu, 20 Feb 2020 02:52:36 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2020 23:52:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,463,1574150400"; d="scan'208";a="349123453" Received: from yhuang-dev.sh.intel.com ([10.239.159.41]) by fmsmga001.fm.intel.com with ESMTP; 19 Feb 2020 23:52:33 -0800 From: "Huang, Ying" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Zi Yan , "Kirill A . Shutemov" , Andrea Arcangeli , Michal Hocko , Vlastimil Babka Subject: [PATCH] mm: Fix possible PMD dirty bit lost in set_pmd_migration_entry() Date: Thu, 20 Feb 2020 15:52:20 +0800 Message-Id: <20200220075220.2327056-1-ying.huang@intel.com> X-Mailer: git-send-email 2.25.0 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 From: Huang Ying In set_pmd_migration_entry(), pmdp_invalidate() is used to change PMD atomically. But the PMD is read before that with an ordinary memory reading. If the THP (transparent huge page) is written between the PMD reading and pmdp_invalidate(), the PMD dirty bit may be lost, and cause data corruption. The race window is quite small, but still possible in theory, so need to be fixed. The race is fixed via using the return value of pmdp_invalidate() to get the original content of PMD, which is a read/modify/write atomic operation. So no THP writing can occur in between. The race has been introduced when the THP migration support is added in the commit 616b8371539a ("mm: thp: enable thp migration in generic path"). But this fix depends on the commit d52605d7cb30 ("mm: do not lose dirty and accessed bits in pmdp_invalidate()"). So it's easy to be backported after v4.16. But the race window is really small, so it may be fine not to backport the fix at all. Signed-off-by: "Huang, Ying" Cc: Zi Yan Cc: Kirill A. Shutemov Cc: Andrea Arcangeli Cc: Michal Hocko Cc: Vlastimil Babka --- mm/huge_memory.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 580098e115bd..b1e069e68189 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3060,8 +3060,7 @@ void set_pmd_migration_entry(struct page_vma_mapped_walk *pvmw, return; flush_cache_range(vma, address, address + HPAGE_PMD_SIZE); - pmdval = *pvmw->pmd; - pmdp_invalidate(vma, address, pvmw->pmd); + pmdval = pmdp_invalidate(vma, address, pvmw->pmd); if (pmd_dirty(pmdval)) set_page_dirty(page); entry = make_migration_entry(page, pmd_write(pmdval)); -- 2.25.0