linux-kernel - Re: [PATCH v3 24/24] pmem: convert to generic memremap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1438622487.9404.2.camel@linux.intel.com>
Date:	Mon, 03 Aug 2015 11:21:27 -0600
From:	Ross Zwisler <ross.zwisler@...ux.intel.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	tglx@...utronix.de, mingo@...nel.org, hpa@...or.com,
	linux-arch@...r.kernel.org, toshi.kani@...com,
	linux-nvdimm@...ts.01.org, mcgrof@...e.com,
	linux-kernel@...r.kernel.org, rmk+kernel@....linux.org.uk,
	hch@....de, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 24/24] pmem: convert to generic memremap

On Thu, 2015-07-30 at 12:55 -0400, Dan Williams wrote:
> Update memremap_pmem() to query the architecture for the mapping type of
> the given persistent memory range  and then pass those flags to generic
> memremap().  arch_memremap_pmem_flags() is provided an address range to
> evaluate in the event an arch has a need for different mapping types by
> address range.  For example the ACPI NFIT carries EFI mapping types in
> its memory range description table.
> 
> Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> ---
>  arch/x86/include/asm/io.h |    2 +-
>  arch/x86/mm/ioremap.c     |   16 ++++++++++------
>  include/linux/pmem.h      |   26 +++++++++++++++-----------
>  3 files changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 1a9d44ee9ed0..26c81b01419c 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -245,7 +245,7 @@ static inline void flush_write_buffers(void)
>  #endif
>  }
>  
> -void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size);
> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size);
>  #endif /* __KERNEL__ */
>  
>  extern void native_io_delay(void);
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index ffbfcf2e701b..5a41e3e4ea1e 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -205,6 +205,16 @@ err_free_memtype:
>  	return NULL;
>  }
>  
> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size)
> +{
> +	/*
> +	 * TODO: check the mapping type provided by platform firmware,
> +	 * per range.
> +	 */
> +	return MEMREMAP_WB;
> +}
> +EXPORT_SYMBOL(arch_memremap_pmem_flags);

I'm not sure that the architecture code has the right information to be able
to tell the caller what the correct mapping is.

I think what you are ultimately looking for is the "Address Range Memory
Mapping Attribute" found in the System Physical Address Range Structure of the
NFIT, right?  (ACPI 6.0, table 5-128)  How can we get to that structure from
nfit-independent architecture code like arch_memremap_pmem_flags()?  It seems
like that if we want to make the mapping type dynamic we should get the flags
from ND when the SPA range is provided by ND, and provide a reasonable default
(WB, it seems) when we are dealing with legacy PMEM?  If PMEM had the flag
from whatever source, it could then pass it in to memremap_pmem(), and get a
mapping of the appropriate caching.

Another option of course is to just ignore the mapping attribute in the NFIT
like we've been doing, and just say "we know WB will be good enough", and
remove the TODO.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/