linux-kernel - Re: [RFC Patch] use MTRR for write combining if PAT is not available

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-next>] [day] [month] [year] [list]

Date:	Tue, 13 Oct 2009 08:34:31 +0100
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	"Thomas Schlichter" <thomas.schlichter@....de>
Cc:	"Jeremy Fitzhardinge" <jeremy.fitzhardinge@...rix.com>,
	"Robert Hancock" <hancockrwd@...il.com>,
	"Henrique de Moraes Holschuh" <hmh@....eng.br>,
	"Suresh Siddha" <suresh.b.siddha@...el.com>,
	"Venkatesh Pallipadi" <venkatesh.pallipadi@...el.com>,
	"Tejun Heo" <tj@...nel.org>, <x86@...nel.org>,
	"Yinghai Lu" <yinghai@...nel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Arjan van de Ven" <arjan@...ux.intel.com>,
	<dri-devel@...ts.sourceforge.net>,
	"Ingo Molnar" <mingo@...hat.com>, <linux-kernel@...r.kernel.org>,
	<jbarnes@...tuousgeek.org>,
	"Thomas Hellstrom" <thellstrom@...are.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not
	 available

>>> Thomas Schlichter <thomas.schlichter@....de> 12.10.09 20:32 >>>
>@@ -268,11 +269,14 @@ EXPORT_SYMBOL(ioremap_nocache);
>  */
> void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
> {
>-	if (pat_enabled)
>-		return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
>-					__builtin_return_address(0));
>-	else
>-		return ioremap_nocache(phys_addr, size);
>+	if (!pat_enabled) {
>+		void __iomem *ret = ioremap_nocache(phys_addr, size);
>+		if (ret)
>+			mtrr_add(phys_addr, size, MTRR_TYPE_WRCOMB, false);

This won't work if phys_addr or size aren't page aligned, or if size isn't
a power of two.

>+		return ret;
>+	}
>+	return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WC,
>+				__builtin_return_address(0));
> }
> EXPORT_SYMBOL(ioremap_wc);
> 
>@@ -1010,8 +1011,13 @@ int set_memory_wc(unsigned long addr, int numpages)
> {
> 	int ret;
> 
>-	if (!pat_enabled)
>-		return set_memory_uc(addr, numpages);
>+	if (!pat_enabled) {
>+		ret = set_memory_uc(addr, numpages);
>+		if (!ret)
>+			mtrr_add(__pa(addr), numpages * PAGE_SIZE,
>+				 MTRR_TYPE_WRCOMB, false);

Similarly, this requires numpages to be a power of two.

>+		return ret;
>+	}
> 
> 	ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
> 		_PAGE_CACHE_WC, NULL);

I think user mode code handles this by splitting the request and trying to
establish as many entries as possible (and those as big as possible).

Also, in all cases you pass 'false' for the 'increment' parameter, in order
to avoid having to tear down the established entries. While this may be
reasonable for kernel initiated mappings, I don't think that's acceptable
for such originating from user mode.

Jan

--
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/