On Mon, 28 Sep 2020 at 07:56, Christophe Leroy <christophe.leroy@xxxxxxxxxx> wrote: > > > > Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit : > > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote: > >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote: > >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote: > >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen > >>>> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > >>>>> > >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote: > >>>>>> The TPM event log is provided to the OS by the firmware, by loading > >>>>>> it into an area in memory and passing the physical address via a node > >>>>>> in the device tree. > >>>>>> > >>>>>> Currently, we use __va() to access the memory via the kernel's linear > >>>>>> map: however, it is not guaranteed that the linear map covers this > >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit > >>>>>> architecture, or running firmware that uses a memory type for the > >>>>>> event log that is omitted from the linear map (such as EfiReserved). > >>>>> > >>>>> Makes perfect sense to the level that I wonder if this should have a > >>>>> fixes tag and/or needs to be backported to the stable kernels? > >>>>> > >>>> > >>>> AIUI, the code was written specifically for ppc64, which is a > >>>> non-highmem, non-EFI architecture. However, when we start reusing this > >>>> driver for ARM, this issue could pop up. > >>>> > >>>> The code itself has been refactored a couple of times, so I think it > >>>> will require different versions of the patch for different generations > >>>> of stable kernels. > >>>> > >>>> So perhaps just add Cc: <stable@xxxxxxxxxxxxxxx>, and wait and see how > >>>> far back it applies cleanly? > >>> > >>> Yeah, I think I'll cc it with some note before the diffstat. > >>> > >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is > >>> dead easy to backport below that. > >> > >> I have this vauge recollection of pointing at this before and being > >> told that it had to be __va for some PPC reason? > >> > >> Do check with the PPC people first, I see none on the CC list. > >> > >> Jason > > > > Thanks, added arch/powerpc maintainers. > > > > As far as I can see, memremap() won't work on PPC32 at least: > > IIUC, memremap() calls arch_memremap_wb() > arch_memremap_wb() calls ioremap_cache() > In case of failure, then ioremap_wt() and ioremap_wc() are tried. > > All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM. > > So the statement "So instead, use memremap(), which will reuse the linear mapping if > it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32. > > Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear > mapping". > It is there, please look again. Before any of the above happens, memremap() will call try_ram_remap() for regions that are covered by a IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and it is not highmem. So as far as I can tell, this change has no effect on PPC at all unless its RAM is not described as IORESOURCE_SYSTEM_RAM.
