From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A427C43381 for ; Wed, 20 Mar 2019 23:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC335218A5 for ; Wed, 20 Mar 2019 23:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553123033; bh=rPHPnf06LLMe2ZK3YH9tTrWrd7gVZPcaOZxbYLNjf9Y=; h=Date:From:To:Subject:List-ID:From; b=aUXbYhhumyDggfSAQREfhjLmzFlMwbrjryPAwcy4Y8cyBhUG+rw/q0gb+583IZ/up LjOugEtLDHBODsRkbp2gaX65VcZBghaX5jDnhq6BuZC0vQwiN9Uq4MVjcmh0zQ1qct HL68APwSqyiK3fuuXNmkIH/0xYKazydjvWf0N51g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727569AbfCTXDw (ORCPT ); Wed, 20 Mar 2019 19:03:52 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45292 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727551AbfCTXDw (ORCPT ); Wed, 20 Mar 2019 19:03:52 -0400 Received: from localhost.localdomain (c-73-223-200-170.hsd1.ca.comcast.net [73.223.200.170]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 753076E70; Wed, 20 Mar 2019 23:03:50 +0000 (UTC) Date: Wed, 20 Mar 2019 16:03:49 -0700 From: akpm@linux-foundation.org To: larper@axis.com, lars.persson@axis.com, mgorman@techsingularity.net, mm-commits@vger.kernel.org, paul.burton@mips.com, ralf@linux-mips.org, stable@vger.kernel.org Subject: + mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch added to -mm tree Message-ID: <20190320230349.Pwb05jh5t%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate has been added to the -mm tree. Its filename is mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Lars Persson Subject: mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate Our MIPS 1004Kc SoCs were seeing random userspace crashes with SIGILL and SIGSEGV that could not be traced back to a userspace code bug. They had all the magic signs of an I/D cache coherency issue. Now recently we noticed that the /proc/sys/vm/compact_memory interface was quite efficient at provoking this class of userspace crashes. Studying the code in mm/migrate.c there is a distinction made between migrating a page that is mapped at the instant of migration and one that is not mapped. Our problem turned out to be the non-mapped pages. For the non-mapped page the code performs a copy of the page content and all relevant meta-data of the page without doing the required D-cache maintenance. This leaves dirty data in the D-cache of the CPU and on the 1004K cores this data is not visible to the I-cache. A subsequent page-fault that triggers a mapping of the page will happily serve the process with potentially stale code. What about ARM then, this bug should have seen greater exposure? Well ARM became immune to this flaw back in 2010, see commit c01778001a4f ("ARM: 6379/1: Assume new page cache pages have dirty D-cache"). My proposed fix moves the D-cache maintenance inside move_to_new_page to make it common for both cases. Link: http://lkml.kernel.org/r/20190315083502.11849-1-larper@axis.com Fixes: 97ee0524614 ("flush cache before installing new page at migraton") Signed-off-by: Lars Persson Reviewed-by: Paul Burton Acked-by: Mel Gorman Cc: Ralf Baechle Cc: Signed-off-by: Andrew Morton --- --- a/mm/migrate.c~mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate +++ a/mm/migrate.c @@ -248,10 +248,8 @@ static bool remove_migration_pte(struct pte = swp_entry_to_pte(entry); } else if (is_device_public_page(new)) { pte = pte_mkdevmap(pte); - flush_dcache_page(new); } - } else - flush_dcache_page(new); + } #ifdef CONFIG_HUGETLB_PAGE if (PageHuge(new)) { @@ -995,6 +993,13 @@ static int move_to_new_page(struct page */ if (!PageMappingFlags(page)) page->mapping = NULL; + + if (unlikely(is_zone_device_page(newpage))) { + if (is_device_public_page(newpage)) + flush_dcache_page(newpage); + } else + flush_dcache_page(newpage); + } out: return rc; _ Patches currently in -mm which might be from lars.persson@axis.com are mm-migrate-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch