Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757033AbcKXObd (ORCPT ); Thu, 24 Nov 2016 09:31:33 -0500 Received: from mail-io0-f171.google.com ([209.85.223.171]:33035 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756801AbcKXObb (ORCPT ); Thu, 24 Nov 2016 09:31:31 -0500 MIME-Version: 1.0 In-Reply-To: <20161124141149.GE2213@rric.localdomain> References: <20161109195132.GZ22012@rric.localdomain> <20161117142528.GJ22855@arm.com> <20161117151805.GJ2151@rric.localdomain> <20161123211538.GH10776@rric.localdomain> <20161124134238.GI10776@rric.localdomain> <20161124135151.GJ10776@rric.localdomain> <20161124141149.GE2213@rric.localdomain> From: Ard Biesheuvel Date: Thu, 24 Nov 2016 14:23:16 +0000 Message-ID: Subject: Re: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section To: Robert Richter Cc: Will Deacon , Robert Richter , Mark Rutland , Catalin Marinas , David Daney , Hanjun Guo , "linux-arm-kernel@lists.infradead.org" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2098 Lines: 50 On 24 November 2016 at 14:11, Robert Richter wrote: > On 24.11.16 13:58:30, Ard Biesheuvel wrote: >> On 24 November 2016 at 13:51, Robert Richter wrote: >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote: >> >> On 24 November 2016 at 13:42, Robert Richter wrote: >> >> > On 23.11.16 21:25:06, Ard Biesheuvel wrote: >> >> >> Why? MEMREMAP_WB is used often, among other things for mapping >> >> >> firmware tables, which are marked as NOMAP, so in these cases, the >> >> >> linear address is not mapped. >> >> > >> >> > If fw tables are mapped wb, that is wrong and needs a separate fix. >> >> > >> >> >> >> Why is that wrong? >> > >> > The whole issue with mapping acpi tables is not marking them cachable, >> > what wb does. >> >> What 'issue'? >> >> > Otherwise we could just use linear mapping for those mem >> > ranges. >> > >> >> Regions containing firmware tables are owned by the firmware, and it >> is the firmware that tells us which memory attributes we are allowed >> to use. If those attributes include WB, it is perfectly legal to use a >> cacheable mapping. That does *not* mean they should be covered by the >> linear mapping. The linear mapping is read-write-non-exec, for >> instance, and we may prefer to use a read-only mapping and/or >> executable mapping. > > Ok, I am going to fix try_ram_remap(). > Thanks. Could you also add an arm64 version of page_is_ram() that uses memblock_is_memory() while you're at it? I think using memblock directly in try_ram_remap() may not be the best approach > Are there other concerns with this patch? > I think we all agree that pfn_valid() should return whether a pfn has a struct page associated with it, the debate is about whether it makes sense to allocate struct pages for memory that the kernel does not own. But given that it does not really hurt to do so for small holes, I think your suggestion makes sense. Should we be doing anything more to ensure that those pages are not dereferenced inadvertently? Is there a page flag we should be setting?