Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp390941img; Tue, 26 Feb 2019 01:48:52 -0800 (PST) X-Google-Smtp-Source: AHgI3IbMZ77Nqm6A5qYaK4h2KT25Jj+tq7XpVycqLQFbT2xhFU6uWMbAxVo7JDkX/oEpSyhGEBcm X-Received: by 2002:a62:1a8c:: with SMTP id a134mr25709512pfa.182.1551174532169; Tue, 26 Feb 2019 01:48:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551174532; cv=none; d=google.com; s=arc-20160816; b=OUxKa2PmYy+AjI5JEJi21txKkWysvaLgmo7Ym2oQIWb4EROIUjkIO1XizqdVGLVoau T2+W9EEi2wrmhv5tW7AxZwXReCAJN5piyM0x2NkVJ6rs0VwJRqv9wFTl5hbD8So4PHom KW8FNA1Ilr6SQQC/A8+NQ4U6/ycoRX/Z9GylvTMMbELkxA01ad08EHenX4hVhkiR/khr WPhSjUJa0OgOrqW8qUZPwxKqUfD3TVQTwfsK2VTvL3/jK/kZaOmrcPR8nUQXUo1kvc5t TFRFbJZ+5ThegEYGazVacLCLtHmPcNz6bgAJXRkF4S3AKvJPZwypoYa03MGy1ZQAmZlF FcCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=thpd36PDMXlf2G7WnhbmXGo66cBy7Bf++yJWkTn0nmw=; b=WHLUa7sHs9H4/azecLBxBHl7F6+Y1azfqOReDqA348UaLeJ0Uqf6A/050j1K18fANZ mm505dgdg5qE+DQsM3wn5KNG1vpcnjo6JB1JbgAznPIOKNtsPGkyW4IKUCb67yopNoWZ MZMWYsHQE+SOf8jKWLu4UC/bBP1XPIIplajvUqUYfPK2oZ7wwqPgTtM16p9DoZLLQE+m F5ixJn/30+dWWghGrLwcvOVAykGG6psIzEUTQpSNuXAelrgbjVmSrHCHq9aprjoDl6wC lBJ3UMBj/ux8l4uA1xmsjN+q0XdbDIYW7tSwS0tbFWYOYijrL8uNpyxaDPn7UxJ3DdjF dmCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bofh-nu.20150623.gappssmtp.com header.s=20150623 header.b="Qd/810rI"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w13si7998277pgr.356.2019.02.26.01.48.36; Tue, 26 Feb 2019 01:48:52 -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; dkim=pass header.i=@bofh-nu.20150623.gappssmtp.com header.s=20150623 header.b="Qd/810rI"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727845AbfBZJqa (ORCPT + 99 others); Tue, 26 Feb 2019 04:46:30 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:36777 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725941AbfBZJq3 (ORCPT ); Tue, 26 Feb 2019 04:46:29 -0500 Received: by mail-oi1-f195.google.com with SMTP id t206so9818487oib.3 for ; Tue, 26 Feb 2019 01:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bofh-nu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=thpd36PDMXlf2G7WnhbmXGo66cBy7Bf++yJWkTn0nmw=; b=Qd/810rIbHZVnn/POX0r7Em7HLJy3zwba5Ohwnh53Y4rfT8lNrK39nxsEiPbwQ5z/I OAySi7W+31UstzKmlYrpgN9aQGi2Ff1sym79XC9ntc2Zn2reUe6pCOJGoJElcwAL68nU bvPwQta3TOcib/542rhHpxwloTVke418JGfEP6Vmyr472U7ir03NT0YlZnp3pCl6dW/R mYzIYcTRDO0TT5nXnNx9ARnLeHYSBaqCofGJnmm417D+mjsfVmf0fQlO/bFkJ0lTGcV7 p2rJ7Qj00svxyjMr/5XQg7BwYqw+WbFumwhSP7lUiboJvd17OeVe26VEjMBLHrNAKG5i y7Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=thpd36PDMXlf2G7WnhbmXGo66cBy7Bf++yJWkTn0nmw=; b=Q7ju2k3OhNKojd4EcTKhMizn8X/WZ+wZxpAsoXNn7dmSnXXl86DWG+DVboEGp6WVzj d1qbsn76UwWJg+H53IMvj2CQ5yaH2rT+EDo/0vM3TQwPZKcYt6+J9mEQCbhbHWczcMy/ FVk2S0jXIOHdCLbOU8Ok/ZW1kUjL1nq4ZzA1uRYaHX4wmBmnVE4PWhyKkfFRZbDRHHqR 6bNZKyRVyTa9Fjc0UDIF4yshotG9SSISEgG0cJVESp90npoBio3W25E9RaSxNCHLR8V1 vUYTy1zJz6ky9DMs882PCufFQN3kVnaMtLxCeyxTRwuFLoaYxc66Ak9rkL0qh7er1L/e BcYA== X-Gm-Message-State: AHQUAubd+S9aIEFkUHUicXoksJtL0c7aeXMj97zKd3rhQMli+r+irAAl bs85EEKEvuqxcxAAb0JR7/56YgouEjMebCWo5Rx9qNuWWaM= X-Received: by 2002:aca:3a0b:: with SMTP id h11mr1823500oia.97.1551174389008; Tue, 26 Feb 2019 01:46:29 -0800 (PST) MIME-Version: 1.0 References: <20190219123212.29838-1-larper@axis.com> <6d12d244-85be-52c4-c3bc-75d077a9c0ee@arm.com> In-Reply-To: <6d12d244-85be-52c4-c3bc-75d077a9c0ee@arm.com> From: Lars Persson Date: Tue, 26 Feb 2019 10:46:18 +0100 Message-ID: Subject: Re: [PATCH] mm: migrate: add missing flush_dcache_page for non-mapped page migrate To: Anshuman Khandual Cc: Lars Persson , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, Lars Persson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 26, 2019 at 10:23 AM Anshuman Khandual wrote: > On 02/19/2019 06:02 PM, Lars Persson wrote: > > 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. > > Just curious. Is not the code path which tries to map this page should > do the invalidation just before setting it up in the page table via > set_pte_at() or other similar variants ? How it maps without doing the > necessary flush. In fact this is what happens when the flush_dcache_page API was used correctly, but it is an arch implementation detail. All kernel code that writes to a page cage page must also call flush_dcache_page before the page becomes eligible for mapping. The arch code has the option to postpone the actual flush until set_pte_at maps the page.