On 24 November 2016 at 14:11, Robert Richter <robert.richter@xxxxxxxxxx> wrote: > On 24.11.16 13:58:30, Ard Biesheuvel wrote: >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@xxxxxxxxxx> wrote: >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote: >> >> On 24 November 2016 at 13:42, Robert Richter <robert.richter@xxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
