Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3824977ybv; Sun, 16 Feb 2020 06:42:27 -0800 (PST) X-Google-Smtp-Source: APXvYqzlnFjEphu0kYg6qk+lt8YKkMy2DTFj+2YXZd+Y/0YCwi3PtOeppJm+6Wl4NX/OehwTyh2e X-Received: by 2002:a9d:7304:: with SMTP id e4mr8400686otk.99.1581864147399; Sun, 16 Feb 2020 06:42:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581864147; cv=none; d=google.com; s=arc-20160816; b=FVbdawZx9R+IgYXVHQv+VrZysBtdAxGW0HEstGh9Bm5PSB+9xfx6EYvWrcBWVZO6EG g3d8j6yb1CktH09tQvU4fmsNeZRNticCYSjUIZizdQcjzvwSlhypya+1toiUvDajKrjF aWCE6Q50sMQs/psraUmhlXVVTow6N1rysEIvlB8Dbgd0B5VAWS9HgN4JtFvutQTecV/g y0Toz8KKTgAdw4kZE+7Qef7erdKVJClPewLbxnEkaeXuaPfotC1oDY8S8wiLzRjr4fc/ 5jZ990W6zZU7tah0cgHWFiz5VBUu6YFJ7m5t2LpowJ9O17UY1wI5oaAzPOcfKOm+RWZe K3uQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Rq4YjsyqC9nG4lp9Qt0VTGxu+aW7XqZ8gTHsGjsUyBU=; b=YZs4FImRmQ8VnCFPOoojCUKnjrUYf3cOC0EALu19nhsN6pz6fTtsYcr10tbE0KekaJ 0CDNgVY4bT2IUDaQE0a5P6jJ0NFYofsL5S5CgAnom0ETHDYL2fcKhpdYXHx/R8tZ7cFv cGD5QrHIWot0AUAH0/io4tLWXsqh9ufoDfrL6mjGkC3h95EPoSBAi99Tt2Zgi8R7GCFT jeTZyCoqBRBasrBHn4kvLtJjK8R27YGT4M+8ssJxTiA666CEiKF8d/78unlXkJpu7fci K9PWf6SjXS+ifgph1LVzgsXQjjMJb3qAutK8Y/HODwrs+5+grBnFNu0PNe9bk4/NyBa1 k8Dg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q25si6550169otg.128.2020.02.16.06.41.43; Sun, 16 Feb 2020 06:42:27 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728208AbgBPOlQ (ORCPT + 99 others); Sun, 16 Feb 2020 09:41:16 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:38011 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728128AbgBPOlQ (ORCPT ); Sun, 16 Feb 2020 09:41:16 -0500 X-Originating-IP: 79.86.19.127 Received: from [192.168.0.12] (127.19.86.79.rev.sfr.net [79.86.19.127]) (Authenticated sender: alex@ghiti.fr) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id A84D120003; Sun, 16 Feb 2020 14:41:11 +0000 (UTC) Subject: Re: [PATCH v2 3/3] riscv: Fix crash when flushing executable ioremap regions To: Jan Kiszka , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org Cc: linux-kernel@vger.kernel.org References: <8a555b0b0934f0ba134de92f6cf9db8b1744316c.1581767384.git.jan.kiszka@web.de> From: Alex Ghiti Message-ID: Date: Sun, 16 Feb 2020 09:41:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <8a555b0b0934f0ba134de92f6cf9db8b1744316c.1581767384.git.jan.kiszka@web.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jan, On 2/15/20 6:49 AM, Jan Kiszka wrote: > From: Jan Kiszka > > Those are not backed by page structs, and pte_page is returning an > invalid pointer. > > Signed-off-by: Jan Kiszka > =2D-- > arch/riscv/mm/cacheflush.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c > index 8930ab7278e6..9ee2c1a387cc 100644 > =2D-- a/arch/riscv/mm/cacheflush.c > +++ b/arch/riscv/mm/cacheflush.c > @@ -84,7 +84,8 @@ void flush_icache_pte(pte_t pte) > { > struct page *page =3D pte_page(pte); > > - if (!test_and_set_bit(PG_dcache_clean, &page->flags)) > + if (!pfn_valid(pte_pfn(pte)) || > + !test_and_set_bit(PG_dcache_clean, &page->flags)) > flush_icache_all(); > } > #endif /* CONFIG_MMU */ > =2D- > 2.16.4 > > When did you encounter such a situation ? i.e. executable code that is not backed by struct page ? Riscv uses the generic implementation of ioremap and the way _PAGE_IOREMAP is defined does not allow to map executable memory region using ioremap, so I'm interested to understand how we end up in flush_icache_pte for an executable region not backed by any struct page. Thanks, Alex