Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp452621imu; Wed, 12 Dec 2018 21:17:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/UvBfSDW2pgacn7uoAeHCPEprzjWjbZI+VcfzhIro4ZLX7qT7zRhcK1rjg6jkZL71ncw/E9 X-Received: by 2002:a63:2d82:: with SMTP id t124mr20600625pgt.260.1544678274969; Wed, 12 Dec 2018 21:17:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544678274; cv=none; d=google.com; s=arc-20160816; b=HPmtJQvYjles3st99QdBhZCX4sPVM3bnbx3jX7Aw5ARHPG65WX7/ZeRuOtc02qnJmo PTpPA8Bgmvwjz6ZWu5Iig/2XSMZh4bEImFfO6J0uzNFYW54JPieqscc57pfAtjiPCVVC 9HkndrmN9+adgUVX/W7rPYkJPCjXutrzBXCh49tppx7RrPJqPNgUfrsfM0nk0b2Ef0bx kQAlyn7LBZTz026JimXJiQU1A4YeqZK54TR0YiVhlaBSJHfXVoYVdXpAf8hOJ53p13T6 GUoFNaX+bTqoqjZGHiBRIpjJCH1ISCFTq6bKqwMuDwBR0dWr0rN92nMS2eJmOb9XrFqc PknQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=1pCCeg5B8HHsS5A8jef8J0DNIcsVkKv/XAUpFPiTDl8=; b=oREr7l9dik2q4yaIe0P/c57OVguGhu6e8mheoG/loph7f26EoM4IC2rlozNqJK2ccK 4UKAfIh3FU+wWXSxMmhwVMsSn+xrDpRbhricIIOAhrEfPPVp6I5FhoQ7gCuD3nQql64O jHON5GbR8qSu5f8YUR6kNs21zwz8lu5S78HcM7xS1laiWl2qRn6R54OtV9fZ6q2mYsZa mV8EOEL5UQN4xkTNwm+9xOBdsWLZiBgYeMGk4qljvE1SMmiB1xqt3ZhoTlb7X5jt80qa qctNo42zUbM5zb9QzTOOKDDIJyCD+wXVnxsLMfLrS1m0JftY5VoOj9LxoTgiZZExTbLb 4/zg== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s84si669545pgs.306.2018.12.12.21.17.38; Wed, 12 Dec 2018 21:17:54 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726777AbeLMFPW (ORCPT + 99 others); Thu, 13 Dec 2018 00:15:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59345 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726542AbeLMFPW (ORCPT ); Thu, 13 Dec 2018 00:15:22 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0774BC05090A; Thu, 13 Dec 2018 05:15:22 +0000 (UTC) Received: from xz-x1.nay.redhat.com (dhcp-14-116.nay.redhat.com [10.66.14.116]) by smtp.corp.redhat.com (Postfix) with ESMTP id 806CC1059582; Thu, 13 Dec 2018 05:15:11 +0000 (UTC) From: Peter Xu To: linux-kernel@vger.kernel.org Cc: peterx@redhat.com, Andrea Arcangeli , Andrew Morton , "Kirill A. Shutemov" , Matthew Wilcox , Michal Hocko , Dave Jiang , "Aneesh Kumar K.V" , Souptick Joarder , Konstantin Khlebnikov , Zi Yan , linux-mm@kvack.org Subject: [PATCH v3] mm: thp: fix flags for pmd migration when split Date: Thu, 13 Dec 2018 13:15:10 +0800 Message-Id: <20181213051510.20306-1-peterx@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 13 Dec 2018 05:15:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When splitting a huge migrating PMD, we'll transfer all the existing PMD bits and apply them again onto the small PTEs. However we are fetching the bits unconditionally via pmd_soft_dirty(), pmd_write() or pmd_yound() while actually they don't make sense at all when it's a migration entry. Fix them up. Since at it, drop the ifdef together as not needed. Note that if my understanding is correct about the problem then if without the patch there is chance to lose some of the dirty bits in the migrating pmd pages (on x86_64 we're fetching bit 11 which is part of swap offset instead of bit 2) and it could potentially corrupt the memory of an userspace program which depends on the dirty bit. CC: Andrea Arcangeli CC: Andrew Morton CC: "Kirill A. Shutemov" CC: Matthew Wilcox CC: Michal Hocko CC: Dave Jiang CC: "Aneesh Kumar K.V" CC: Souptick Joarder CC: Konstantin Khlebnikov CC: Zi Yan CC: linux-mm@kvack.org CC: linux-kernel@vger.kernel.org Signed-off-by: Peter Xu --- v2: - fix it up for young/write/dirty bits too [Konstantin] v3: - fetch write correctly for migration entry; drop macro [Konstantin] --- mm/huge_memory.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index f2d19e4fe854..aebade83cec9 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2145,23 +2145,25 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, */ old_pmd = pmdp_invalidate(vma, haddr, pmd); -#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION pmd_migration = is_pmd_migration_entry(old_pmd); - if (pmd_migration) { + if (unlikely(pmd_migration)) { swp_entry_t entry; entry = pmd_to_swp_entry(old_pmd); page = pfn_to_page(swp_offset(entry)); - } else -#endif + write = is_write_migration_entry(entry); + young = false; + soft_dirty = pmd_swp_soft_dirty(old_pmd); + } else { page = pmd_page(old_pmd); + if (pmd_dirty(old_pmd)) + SetPageDirty(page); + write = pmd_write(old_pmd); + young = pmd_young(old_pmd); + soft_dirty = pmd_soft_dirty(old_pmd); + } VM_BUG_ON_PAGE(!page_count(page), page); page_ref_add(page, HPAGE_PMD_NR - 1); - if (pmd_dirty(old_pmd)) - SetPageDirty(page); - write = pmd_write(old_pmd); - young = pmd_young(old_pmd); - soft_dirty = pmd_soft_dirty(old_pmd); /* * Withdraw the table only after we mark the pmd entry invalid. -- 2.17.1