mtrr/x86/drivers: bury MTRR

This patch adds an additional argument, 'uniform', to mtrr_type_lookup(), which returns 1 when a given range is covered uniformly by MTRRs, i.e. the range is fully covered by a single MTRR entry or the default type.

pud_set_huge() and pmd_set_huge() are changed to check the new 'uniform' flag to see if it is safe to create a huge page mapping to the range. This allows them to create a huge page mapping to a range covered by a single MTRR entry of any memory type. It also detects a non-optimal request properly. They continue to check with the WB type since the WB type has no effect even if a request spans multiple MTRR entries.

pmd_set_huge() logs a warning message to a non-optimal request so that driver writers will be aware of such a case. Drivers should make a mapping request aligned to a single MTRR entry when the range is covered by MTRRs.

Signed-off-by Toshi Kani <[email protected]>

---
 arch/x86/include/asm/mtrr.h        |    5 +++--
 arch/x86/kernel/cpu/mtrr/generic.c |   35 +++++++++++++++++++++++++++--------
 arch/x86/mm/pat.c                  |    4 ++--
 arch/x86/mm/pgtable.c              |   25 +++++++++++++++----------
 4 files changed, 47 insertions(+), 22 deletions(-)

arch/x86/kernel/cpu/mtrr/generic.c +5 -2

@@ -253,14 +264,17 @@ u8 mtrr_type_lookup(u64 start, u64 end)
 	 * the variable ranges.
 	 */
 	type = mtrr_type_lookup_fixed(start, end);
-	if (type != MTRR_TYPE_INVALID)
+	if (type != MTRR_TYPE_INVALID) {
+		*uniform = 0;
 		return type;
+	}
 
 	/*
 	 * Look up the variable ranges.  Look of multiple ranges matching
 	 * this address and pick type as per MTRR precedence.
 	 */
-	type = mtrr_type_lookup_variable(start, end, &partial_end, &repeat);
+	type = mtrr_type_lookup_variable(start, end, &partial_end,
+					 &repeat, &is_uniform);
 
 	/*
 	 * Common path is with repeat = 0.

arch/x86/kernel/cpu/mtrr/generic.c +6 -2

+
 		type = mtrr_type_lookup_variable(start, end, &partial_end,
-						 &repeat);
+						 &repeat, &dummy);
 
-		if (check_type_overlap(&prev_type, &type))
+		if (check_type_overlap(&prev_type, &type)) {
+			*uniform = 0;
 			return type;
+		}
 	}
 
 	if (mtrr_tom2 && (start >= (1ULL<<32)) && (end < mtrr_tom2))
 		return MTRR_TYPE_WRBACK;
 
+	*uniform = is_uniform;
 	return type;
 }
 

arch/x86/mm/pat.c +2 -2

index 35af677..372ad42 100644
@@ -267,9 +267,9 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
 	 * request is for WB.
 	 */
 	if (req_type == _PAGE_CACHE_MODE_WB) {
-		u8 mtrr_type;
+		u8 mtrr_type, uniform;
 
-		mtrr_type = mtrr_type_lookup(start, end);
+		mtrr_type = mtrr_type_lookup(start, end, &uniform);
 		if (mtrr_type != MTRR_TYPE_WRBACK)
 			return _PAGE_CACHE_MODE_UC_MINUS;
 

arch/x86/mm/pgtable.c +9 -7

index cfca4cf..3d6edea 100644
@@ -567,17 +567,18 @@ void native_set_fixmap(enum fixed_addresses idx, phys_addr_t phys,
  * pud_set_huge - setup kernel PUD mapping
  *
  * MTRR can override PAT memory types with 4KB granularity.  Therefore,
- * it does not set up a huge page when the range is covered by a non-WB
- * type of MTRR.  MTRR_TYPE_INVALID indicates that MTRR are disabled.
+ * it only sets up a huge page when the range is mapped uniformly by MTRR
+ * (i.e. the range is fully covered by a single MTRR entry or the default
+ * type) or the MTRR memory type is WB.
  *
  * Return 1 on success, and 0 when no PUD was set.
  */
 int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
 {
-	u8 mtrr;
+	u8 mtrr, uniform;
 
-	mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE);
-	if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != MTRR_TYPE_INVALID))
+	mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE, &uniform);
+	if ((!uniform) && (mtrr != MTRR_TYPE_WRBACK))
 		return 0;
 
 	prot = pgprot_4k_2_large(prot);

@@ -593,18 +594,22 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
  * pmd_set_huge - setup kernel PMD mapping
  *
  * MTRR can override PAT memory types with 4KB granularity.  Therefore,
- * it does not set up a huge page when the range is covered by a non-WB
- * type of MTRR.  MTRR_TYPE_INVALID indicates that MTRR are disabled.
+ * it only sets up a huge page when the range is mapped uniformly by MTRR
+ * (i.e. the range is fully covered by a single MTRR entry or the default
+ * type) or the MTRR memory type is WB.
  *
  * Return 1 on success, and 0 when no PMD was set.
  */
 int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
 {

On Tue, Mar 24, 2015 at 04:08:41PM -0600, Toshi Kani wrote:

arch/x86/kernel/cpu/mtrr/generic.c static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end, · line 246

Quoted 8 lines

arch/x86/kernel/cpu/mtrr/generic.c +4 -0

@@ -235,13 +240,19 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end,
  * Return Values:
  * MTRR_TYPE_(type)  - The effective MTRR type for the region
  * MTRR_TYPE_INVALID - MTRR is disabled
+ *
+ * Output Argument:
+ * uniform - Set to 1 when MTRR covers the region uniformly, i.e. the region
+ *	     is fully covered by a single MTRR entry or the default type.

I'd call this "single_mtrr". "uniform" could also mean that the resulting type is uniform, i.e. of the same type but spanning multiple MTRRs.

arch/x86/kernel/cpu/mtrr/generic.c static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end, · line 255

Quoted 11 lines

arch/x86/kernel/cpu/mtrr/generic.c +4 -2

  */
-u8 mtrr_type_lookup(u64 start, u64 end)
+u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
 {
-	u8 type, prev_type;
+	u8 type, prev_type, is_uniform, dummy;
 	int repeat;
 	u64 partial_end;
 
+	*uniform = 1;
+

You're setting it here...

arch/x86/kernel/cpu/mtrr/generic.c static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end, · line 257

Quoted 2 lines

arch/x86/kernel/cpu/mtrr/generic.c +0 -0

 	if (!mtrr_state_set)
 		return MTRR_TYPE_INVALID;

... but if you return here, you would've changed the thing uniform points to needlessly as you're returning an error.

Quoted 21 lines

arch/x86/kernel/cpu/mtrr/generic.c +5 -2

@@ -253,14 +264,17 @@ u8 mtrr_type_lookup(u64 start, u64 end)
 	 * the variable ranges.
 	 */
 	type = mtrr_type_lookup_fixed(start, end);
-	if (type != MTRR_TYPE_INVALID)
+	if (type != MTRR_TYPE_INVALID) {
+		*uniform = 0;
 		return type;
+	}
 
 	/*
 	 * Look up the variable ranges.  Look of multiple ranges matching
 	 * this address and pick type as per MTRR precedence.
 	 */
-	type = mtrr_type_lookup_variable(start, end, &partial_end, &repeat);
+	type = mtrr_type_lookup_variable(start, end, &partial_end,
+					 &repeat, &is_uniform);
 
 	/*
 	 * Common path is with repeat = 0.

arch/x86/kernel/cpu/mtrr/generic.c u8 mtrr_type_lookup(u64 start, u64 end) · line 288

Quoted 4 lines

arch/x86/kernel/cpu/mtrr/generic.c +1 -0

@@ -271,16 +285,21 @@ u8 mtrr_type_lookup(u64 start, u64 end)
 	while (repeat) {
 		prev_type = type;
 		start = partial_end;
+		is_uniform = 0;

So I think it would be better if you added an out: label where you do exit from the function and set return values there.

So something like that, I'm pasting the whole function here so that you can follow better:

This way you're setting the uniform pointer in a single location and you're working with the local variable inside the function.

Much easier to follow.

arch/x86/mm/pgtable.c int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot) · line 611

Quoted 13 lines

arch/x86/mm/pgtable.c +5 -3

  */
 int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
 {
-	u8 mtrr;
+	u8 mtrr, uniform;
 
-	mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE);
-	if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != MTRR_TYPE_INVALID))
+	mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform);
+	if ((!uniform) && (mtrr != MTRR_TYPE_WRBACK)) {
+		pr_warn("pmd_set_huge: requesting [mem %#010llx-%#010llx], which spans more than a single MTRR entry\n",
+				addr, addr + PMD_SIZE);
 		return 0;

So this returns 0, i.e. failure already. Why do we even have to warn? Caller already knows it failed.

And this warning would flood dmesg needlessly.

Quoted 11 lines

arch/x86/kernel/cpu/mtrr/generic.c static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end, · line 246

Quoted 8 lines

arch/x86/kernel/cpu/mtrr/generic.c +4 -0

@@ -235,13 +240,19 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end,
  * Return Values:
  * MTRR_TYPE_(type)  - The effective MTRR type for the region
  * MTRR_TYPE_INVALID - MTRR is disabled
+ *
+ * Output Argument:
+ * uniform - Set to 1 when MTRR covers the region uniformly, i.e. the region
+ *	     is fully covered by a single MTRR entry or the default type.

I'd call this "single_mtrr". "uniform" could also mean that the resulting type is uniform, i.e. of the same type but spanning multiple MTRRs.

Actually, that is the intend of "uniform" and the same type but spanning multiple MTRRs should set "uniform" to 1. The patch does not check such

We need to set "uniform" to 1 when MTRRs are disabled since there is no type conflict with MTRRs.

The warning was suggested by reviewers in the previous review so that driver writers will notice the issue.

Returning 0 here will lead
ioremap() to use 4KB mappings, but does not cause ioremap() to fail.

Quoted 12 lines · Toshi Kani

Quoted 11 lines

arch/x86/kernel/cpu/mtrr/generic.c static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end, · line 246

Quoted 8 lines

arch/x86/kernel/cpu/mtrr/generic.c +4 -0

@@ -235,13 +240,19 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64 *partial_end,
  * Return Values:
  * MTRR_TYPE_(type)  - The effective MTRR type for the region
  * MTRR_TYPE_INVALID - MTRR is disabled
+ *
+ * Output Argument:
+ * uniform - Set to 1 when MTRR covers the region uniformly, i.e. the region
+ *	     is fully covered by a single MTRR entry or the default type.

I'd call this "single_mtrr". "uniform" could also mean that the resulting type is uniform, i.e. of the same type but spanning multiple MTRRs.

Quoted 2 lines

Actually, that is the intend of "uniform" and the same type but spanning multiple MTRRs should set "uniform" to 1. The patch does not check such

So why does it say "is fully covered by a single MTRR entry or the default type." - the stress being on *single*

You need to make up your mind.

Quoted 2 lines

We need to set "uniform" to 1 when MTRRs are disabled since there is no type conflict with MTRRs.

No, this is wrong.

When we return an *error*, "uniform" should be *undefined* because MTRRs are disabled and callers should be checking whether it returned an error first and only *then* look at uniform.

Quoted 2 lines

The warning was suggested by reviewers in the previous review so that driver writers will notice the issue.

No, we don't flood dmesg so that driver writers notice stuff. We better fix the callers.

Quoted 2 lines

Returning 0 here will lead
ioremap() to use 4KB mappings, but does not cause ioremap() to fail.

I guess a pr_warn_once() should be better then. Flooding dmesg with error messages for which the user can't really do anything about doesn't bring us anything.

MTRRs disabled is not an error case as it could be a normal configuration on some platforms / BIOS setups.

I clarified it in the above comment that uniform is set for any return value.

Quoted 2 lines · Toshi Kani

MTRRs disabled is not an error case as it could be a normal configuration on some platforms / BIOS setups.

Normal how? PAT-only systems? Examples please...

Quoted 2 lines

I clarified it in the above comment that uniform is set for any return value.

Hell no!

u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform) {

	...

        *uniform = 1;

        if (!mtrr_state_set)
                return MTRR_TYPE_INVALID;

        if (!(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED))
                return MTRR_TYPE_INVALID;

This is wrong and the fact that I still need to persuade you about it says a lot.

If you want to be able to state that a type is uniform even if MTRRs are disabled, you need to define another retval which means exactly that.

Or add an inline function called mtrr_enabled() and call it in the mtrr_type_lookup() callers.

Or whatever.

I don't want any confusing states with two return types and people having to figure out what it exactly means and digging into the code and scratching heads WTF is that supposed to mean.

There may not be any type conflict with MTRR_TYPE_INVALID.

I will change the caller to check MTRR_TYPE_INVALID, and treat it as a uniform case.

Quoted 1 line · Toshi Kani

There may not be any type conflict with MTRR_TYPE_INVALID.

Because...?

Let me guess: you cannot change this function to return a signed value which is the type when positive and an error when negative?

Quoted 2 lines

I will change the caller to check MTRR_TYPE_INVALID, and treat it as a uniform case.

That would be, of course, also wrong.

MTRR_TYPE_INVALID means MTRRs disabled. So, the caller checking with this value is the same as checking with mtrr_enabled() you suggested.

Quoted 2 lines · Toshi Kani

MTRR_TYPE_INVALID means MTRRs disabled. So, the caller checking with this value is the same as checking with mtrr_enabled() you suggested.

So then you don't have to set *uniform = 1 on entry to mtrr_type_lookup(). And change the retval test

	if ((!uniform) && (mtrr != MTRR_TYPE_WRBACK))

to

	if ((mtrr != MTRR_TYPE_INVALID) && (!uniform) && (mtrr != MTRR_TYPE_WRBACK))

You can put the MTRR_TYPE_INVALID first so that it shortcuts.

You need the distinction between MTRRs *disabled* and an MTRR region being {non-,}uniform.

If MTRRs are disabled, uniform doesn't *mean* *anything* because it is undefined. When MTRRs are disabled, the range is *not* covered by MTRRs because, well, them MTRRs are disabled.

And it might be fine for *your* use case to set *uniform even when MTRRs are disabled but it might matter in the future. So we better design it correct from the beginning.

This patchset enhances MTRR checks for the kernel huge I/O mapping, which was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589

The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page mapping to a range covered by a single MTRR entry of any memory type.
- Log a pr_warn() message when a specified PMD map range spans more than a single MTRR entry. Drivers should make a mapping request aligned to a single MTRR entry when the range is covered by MTRRs.

Quoted 4 lines · On Tue, 24 Mar 2015 16:08:34 -0600 Toshi Kani <[email protected]> wrote:

This patchset enhances MTRR checks for the kernel huge I/O mapping, which was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589

Quoted 8 lines

The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page mapping to a range covered by a single MTRR entry of any memory type.
- Log a pr_warn() message when a specified PMD map range spans more than a single MTRR entry. Drivers should make a mapping request aligned to a single MTRR entry when the range is covered by MTRRs.

OK, I grabbed these after barely looking at them, to get them a bit of runtime testing.

I'll await guidance from the x86 maintainers regarding next steps?

Quoted 18 lines · Andrew Morton

Quoted 4 lines · On Tue, 24 Mar 2015 16:08:34 -0600 Toshi Kani <[email protected]> wrote:

This patchset enhances MTRR checks for the kernel huge I/O mapping, which was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589

Quoted 8 lines

The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page mapping to a range covered by a single MTRR entry of any memory type.
- Log a pr_warn() message when a specified PMD map range spans more than a single MTRR entry. Drivers should make a mapping request aligned to a single MTRR entry when the range is covered by MTRRs.

OK, I grabbed these after barely looking at them, to get them a bit of runtime testing.

Quoted 1 line

I'll await guidance from the x86 maintainers regarding next steps?

Could you please send the current version of them over to us if your testing didn't find any problems?

I'd like to take a final look and have them cook in the x86 tree as well for a while and want to preserve your testing effort.

Quoted 22 lines · Ingo Molnar

Quoted 19 lines · Andrew Morton

Quoted 4 lines · On Tue, 24 Mar 2015 16:08:34 -0600 Toshi Kani <[email protected]> wrote:

This patchset enhances MTRR checks for the kernel huge I/O mapping, which was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589

Quoted 8 lines

The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page mapping to a range covered by a single MTRR entry of any memory type.
- Log a pr_warn() message when a specified PMD map range spans more than a single MTRR entry. Drivers should make a mapping request aligned to a single MTRR entry when the range is covered by MTRRs.

OK, I grabbed these after barely looking at them, to get them a bit of runtime testing.

I'll await guidance from the x86 maintainers regarding next steps?

Quoted 5 lines

Could you please send the current version of them over to us if your testing didn't find any problems?

I'd like to take a final look and have them cook in the x86 tree as well for a while and want to preserve your testing effort.

This patchset is on top of the following patches in the -mm tree. (Patches apply from the bottom to the top.)

2. Build error fixes and cleanups
http://ozlabs.org/~akpm/mmotm/broken-out/x86-mm-support-huge-kva-mappings-on-x86-fix.patch
http://ozlabs.org/~akpm/mmotm/broken-out/mm-change-vunmap-to-tear-down-huge-kva-mappings-fix.patch
http://ozlabs.org/~akpm/mmotm/broken-out/mm-change-ioremap-to-set-up-huge-i-o-mappings-fix.patch
http://ozlabs.org/~akpm/mmotm/broken-out/lib-add-huge-i-o-map-capability-interfaces-fix.patch

1. Kernel huge I/O mapping support
http://ozlabs.org/~akpm/mmotm/broken-out/x86-mm-support-huge-kva-mappings-on-x86.patch
http://ozlabs.org/~akpm/mmotm/broken-out/x86-mm-support-huge-i-o-mapping-capability-i-f.patch
http://ozlabs.org/~akpm/mmotm/broken-out/mm-change-vunmap-to-tear-down-huge-kva-mappings.patch
http://ozlabs.org/~akpm/mmotm/broken-out/mm-change-ioremap-to-set-up-huge-i-o-mappings.patch
http://ozlabs.org/~akpm/mmotm/broken-out/lib-add-huge-i-o-map-capability-interfaces.patch
http://ozlabs.org/~akpm/mmotm/broken-out/mm-change-__get_vm_area_node-to-use-fls_long.patch

Thanks,
-Toshi

Documentation/x86/boot.txt labels the bit in boot_params.hdr.loadflags as ALSR_FLAG while it should be KASLR_FLAG.

Signed-off-by Miroslav Benes <[email protected]>

---
 Documentation/x86/boot.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Documentation/x86/boot.txt +0 -0

index 88b8589..69e1397 100644

The current algorithm used in clflush_cache_range() can cause the last cache line of the buffer to be flushed twice. Fix that algorithm so that each cache line will only be flushed once.

Signed-off-by Ross Zwisler <[email protected]>

Reported-by H. Peter Anvin <[email protected]>

Cc H. Peter Anvin <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc [email protected]

Cc Borislav Petkov <[email protected]>

---
 arch/x86/mm/pageattr.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

Add kerneldoc comments for pcommit_sfence() describing the purpose of the pcommit instruction and demonstrating the usage of that instruction.

Signed-off-by Ross Zwisler <[email protected]>

Cc H Peter Anvin <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Borislav Petkov <[email protected]>

---

From: "Luis R. Rodriguez" <[email protected]>

ioremap_nocache() currently uses UC- by default. Our goal is to eventually make UC the default. Linux maps UC- to PCD=1, PWT=0 page attributes on non-PAT systems. Linux maps UC to PCD=1, PWT=1 page attributes on non-PAT systems. On non-PAT and PAT systems a WC MTRR has different effects on pages with either of these attributes. In order to help with a smooth transition its best to enable use of UC (PCD,1, PWT=1) on a region as that ensures a WC MTRR will have no effect on a region, this however requires us to have an way to declare a region as UC and we currently do not have a way to do this.

WC MTRR on non-PAT system with PCD=1, PWT=0 (UC-) yields WC. WC MTRR on non-PAT system with PCD=1, PWT=1 (UC) yields UC.

WC MTRR on PAT system with PCD=1, PWT=0 (UC-) yields WC. WC MTRR on PAT system with PCD=1, PWT=1 (UC) yields UC.

A flip of the default ioremap_nocache() behaviour from UC- to UC can therefore regress a memory region from effective memory type WC to UC if MTRRs are used. Use of MTRRs should be phased out and in the best case only arch_phys_wc_add() use will remain, even if this happens arch_phys_wc_add() will have an effect on non-PAT systems and changes to default ioremap_nocache() behaviour could regress drivers.

Now, ideally we'd use ioremap_nocache() on the regions in which we'd need uncachable memory types and avoid any MTRRs on those regions. There are however some restrictions on MTRRs use, such as the requirement of having the base and size of variable sized MTRRs to be powers of two, which could mean having to use a WC MTRR over a large area which includes a region in which write-combining effects are undesirable.

Add ioremap_uc() to help with the both phasing out of MTRR use and also provide a way to blacklist small WC undesirable regions in devices with mixed regions which are size-implicated to use large WC MTRRs. Use of ioremap_uc() helps phase out MTRR use by avoiding regressions with an eventual flip of default behaviour or ioremap_nocache() from UC- to UC.

Drivers working with WC MTRRs can use the below table to review and consider the use of ioremap*() and similar helpers to ensure appropriate behaviour long term even if default ioremap_nocache() behaviour changes from UC- to UC.

Although ioremap_uc() is being added we leave set_memory_uc() to use UC- as only initial memory type setup is required to be able to accomodate existing device drivers and phase out MTRR use. It should also be clarified that set_memory_uc() cannot be used with IO memory, even though its use will not return any errors, it really has no effect.

----------------------------------------------------------------------
MTRR Non-PAT PAT Linux ioremap value Effective memory type
----------------------------------------------------------------------

                                                  Non-PAT |  PAT
     PAT
     |PCD
     ||PWT
     |||
WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC

----------------------------------------------------------------------

Cc Toshi Kani <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Bjorn Helgaas <[email protected]>

Cc Suresh Siddha <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Juergen Gross <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Dave Airlie <[email protected]>

Cc Antonino Daplas <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

Cc Tomi Valkeinen <[email protected]>

Cc Ville Syrjälä <[email protected]>

Cc Will Deacon <[email protected]>

Cc Thierry Reding <[email protected]>

Cc Mike Travis <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Davidlohr Bueso <[email protected]>

Cc [email protected]

Cc [email protected]

Cc [email protected]

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 arch/x86/include/asm/io.h |  1 +
 arch/x86/mm/ioremap.c     | 36 +++++++++++++++++++++++++++++++++++-
 arch/x86/mm/pageattr.c    |  3 +++
 include/asm-generic/io.h  |  8 ++++++++
 4 files changed, 47 insertions(+), 1 deletion(-)

From: "Luis R. Rodriguez" <[email protected]>

---
 Documentation/x86/mtrr.txt      | 18 +++++++++++++++---
 Documentation/x86/pat.txt       | 40 +++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/cpu/mtrr/main.c |  3 +++
 3 files changed, 57 insertions(+), 4 deletions(-)

Documentation/x86/pat.txt +0 -1

index cf08c9f..7e183e3 100644
@@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
 as step 0 above and also track the usage of those pages and use set_memory_wb()
 before the page is freed to free pool.
 
-

Documentation/x86/pat.txt +21 -0

+where otherwise MTRR write-combining would not be effective.
+
+Note that you cannot use set_memory_wc() to override / whitelist IO remapped
+memory space mapped with ioremap*() calls, set_memory_wc() can only be used
+on RAM.
+
+----------------------------------------------------------------------
+MTRR Non-PAT   PAT    Linux ioremap value        Effective memory type
+----------------------------------------------------------------------
+                                                  Non-PAT |  PAT
+     PAT
+     |PCD
+     ||PWT
+     |||
+WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
+WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
+WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
+WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
 
 Notes:
 

arch/x86/kernel/cpu/mtrr/main.c +0 -0

index ea5f363..12abdbe 100644

arch/x86/kernel/cpu/mtrr/main.c +2 -0

+ * equivalent power of two boundary.
+ *
  * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
  * but drivers should not try to interpret that return value.
  */

Quoted 10 lines · Luis R. Rodriguez

From: "Luis R. Rodriguez" <[email protected]>

Documentation/x86/pat.txt +0 -1

index cf08c9f..7e183e3 100644
@@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
 as step 0 above and also track the usage of those pages and use set_memory_wb()
 before the page is freed to free pool.
 
-

Documentation/x86/pat.txt wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc() · line 116

Quoted 10 lines

Documentation/x86/pat.txt +10 -0

+MTRR effects on PAT / non-PAT systems
+-------------------------------------
+
+The following table provides the effects of using write-combining MTRRs when
+using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
+mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
+be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+is made should already have be ioremap'd with write-combining page attributes
+or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
+Devices which combine areas of IO memory desired to remain uncachable with

I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds 14 hits vs. 6 hits for uncachable. No big deal.

Documentation/x86/pat.txt wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc() · line 122

Quoted 6 lines

Documentation/x86/pat.txt +6 -0

+areas where write-combining is desirable and are restricted by the size
+requirements of MTRRs should consider splitting up their IO memory space
+cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
+encompassing both regions. Such use is nevertheless heavily discouraged as
+the effective memory type is considered implementation defined. This strategy
+should only be used as last resort on devices with size-contrained regions

size-constrained

Quoted 24 lines

Documentation/x86/pat.txt +21 -0

+where otherwise MTRR write-combining would not be effective.
+
+Note that you cannot use set_memory_wc() to override / whitelist IO remapped
+memory space mapped with ioremap*() calls, set_memory_wc() can only be used
+on RAM.
+
+----------------------------------------------------------------------
+MTRR Non-PAT   PAT    Linux ioremap value        Effective memory type
+----------------------------------------------------------------------
+                                                  Non-PAT |  PAT
+     PAT
+     |PCD
+     ||PWT
+     |||
+WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
+WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
+WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
+WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
 
 Notes:
 

arch/x86/kernel/cpu/mtrr/main.c EXPORT_SYMBOL(mtrr_del); · line 541

Quoted 9 lines

arch/x86/kernel/cpu/mtrr/main.c +1 -0

index ea5f363..12abdbe 100644
@@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
  * attempts to add a WC MTRR covering size bytes starting at base and
  * logs an error if this fails.
  *
+ * The caller should expect to need to provide a power of two size on an

* The called should provide a power of two size on an equivalent
* power of two boundary.

Thanks since Boris took this already I'll let him amend unless he wishes for me to send a new version.

Quoted 2 lines · Luis R. Rodriguez

Thanks since Boris took this already I'll let him amend unless he wishes for me to send a new version.

Haven't. I'm waiting for v2.

If so since they depend on ioremap_uc() should it go through Boris as he's taking that in?

Quoted 17 lines · Luis R. Rodriguez

From: "Luis R. Rodriguez" <[email protected]>

---
 Documentation/x86/mtrr.txt      | 18 +++++++++++++++---
 Documentation/x86/pat.txt       | 40 +++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/cpu/mtrr/main.c |  3 +++
 3 files changed, 57 insertions(+), 4 deletions(-)

Documentation/x86/pat.txt +0 -0

index cf08c9f..7e183e3 100644
@@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
 as step 0 above and also track the usage of those pages and use set_memory_wb()
 before the page is freed to free pool.
 

Documentation/x86/pat.txt wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc() · line 116

Quoted 11 lines

Documentation/x86/pat.txt +10 -1

-
+MTRR effects on PAT / non-PAT systems
+-------------------------------------
+
+The following table provides the effects of using write-combining MTRRs when
+using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
+mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
+be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+is made should already have be ioremap'd with write-combining page attributes
+or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
+Devices which combine areas of IO memory desired to remain uncachable with

I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds 14 hits vs. 6 hits for uncachable. No big deal.

Documentation/x86/pat.txt wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc() · line 122

Quoted 6 lines

Documentation/x86/pat.txt +6 -0

+areas where write-combining is desirable and are restricted by the size
+requirements of MTRRs should consider splitting up their IO memory space
+cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
+encompassing both regions. Such use is nevertheless heavily discouraged as
+the effective memory type is considered implementation defined. This strategy
+should only be used as last resort on devices with size-contrained regions

size-constrained

Quoted 24 lines

Documentation/x86/pat.txt +21 -0

+where otherwise MTRR write-combining would not be effective.
+
+Note that you cannot use set_memory_wc() to override / whitelist IO remapped
+memory space mapped with ioremap*() calls, set_memory_wc() can only be used
+on RAM.
+
+----------------------------------------------------------------------
+MTRR Non-PAT   PAT    Linux ioremap value        Effective memory type
+----------------------------------------------------------------------
+                                                  Non-PAT |  PAT
+     PAT
+     |PCD
+     ||PWT
+     |||
+WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
+WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
+WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
+WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
 
 Notes:
 

arch/x86/kernel/cpu/mtrr/main.c EXPORT_SYMBOL(mtrr_del); · line 541

Quoted 9 lines

arch/x86/kernel/cpu/mtrr/main.c +1 -0

index ea5f363..12abdbe 100644
@@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
  * attempts to add a WC MTRR covering size bytes starting at base and
  * logs an error if this fails.
  *
+ * The caller should expect to need to provide a power of two size on an

* The called should provide a power of two size on an equivalent
* power of two boundary.

From: "Luis R. Rodriguez" <[email protected]>

As part of the effort to phase out MTRR use document write-combining MTRR effects on pages with different non-PAT page attributes flags and different PAT entry values. Extend arch_phys_wc_add() documentation to clarify power of two sizes / boundary requirements as we phase out mtrr_add() use.

Lastly hint towards ioremap_uc() for corner cases on device drivers working with devices with mixed regions where MTRR size requirements would otherwise not enable write-combining effective memory types.

Cc Toshi Kani <[email protected]>

Cc Jonathan Corbet <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Suresh Siddha <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Juergen Gross <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Dave Airlie <[email protected]>

Cc Antonino Daplas <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

Cc Tomi Valkeinen <[email protected]>

Cc Ville Syrjälä <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Davidlohr Bueso <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 Documentation/x86/mtrr.txt      | 18 +++++++++++++++---
 Documentation/x86/pat.txt       | 40 +++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/cpu/mtrr/main.c |  3 +++
 3 files changed, 57 insertions(+), 4 deletions(-)

Documentation/x86/mtrr.txt +0 -0

index cc071dc..a111a6c 100644

Documentation/x86/mtrr.txt +9 -0

+
+MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
+of effective MTRR that is expected to be supported will be for write-combining.
+As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
+MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
+
+For details refer to Documentation/x86/pat.txt.
+
+=======================================>  
   On Intel P6 family processors (Pentium Pro, Pentium II and later)
   the Memory Type Range Registers (MTRRs) may be used to control

Documentation/x86/pat.txt +2 -0

index cf08c9f..7e183e3 100644
@@ -34,6 +34,8 @@ ioremap                |    --    |    UC-     |       UC-        |
                        |          |            |                  |
 ioremap_cache          |    --    |    WB      |       WB         |
                        |          |            |                  |
+ioremap_uc             |    --    |    UC      |       UC         |
+                       |          |            |                  |
 ioremap_nocache        |    --    |    UC-     |       UC-        |
                        |          |            |                  |
 ioremap_wc             |    --    |    --      |       WC         |

Documentation/x86/pat.txt +29 -0

+or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
+Devices which combine areas of IO memory desired to remain uncachable with
+areas where write-combining is desirable and are restricted by the size
+requirements of MTRRs should consider splitting up their IO memory space
+cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
+encompassing both regions. Such use is nevertheless heavily discouraged as
+the effective memory type is considered implementation defined. This strategy
+should only be used as last resort on devices with size-contrained regions
+where otherwise MTRR write-combining would not be effective.
+
+Note that you cannot use set_memory_wc() to override / whitelist IO remapped
+memory space mapped with ioremap*() calls, set_memory_wc() can only be used
+on RAM.
+
+----------------------------------------------------------------------
+MTRR Non-PAT   PAT    Linux ioremap value        Effective memory type
+----------------------------------------------------------------------
+                                                  Non-PAT |  PAT
+     PAT
+     |PCD
+     ||PWT
+     |||
+WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
+WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
+WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
+WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
 
 Notes:
 

arch/x86/kernel/cpu/mtrr/main.c +3 -0

index ea5f363..12abdbe 100644
@@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
  * attempts to add a WC MTRR covering size bytes starting at base and
  * logs an error if this fails.
  *
+ * The caller should expect to need to provide a power of two size on an
+ * equivalent power of two boundary.
+ *
  * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
  * but drivers should not try to interpret that return value.
  */

Signature · 1 line

2.3.2.209.gd67f9d5.dirty

Quoted 41 lines · Luis R. Rodriguez

From: "Luis R. Rodriguez" <[email protected]>

As part of the effort to phase out MTRR use document write-combining MTRR effects on pages with different non-PAT page attributes flags and different PAT entry values. Extend arch_phys_wc_add() documentation to clarify power of two sizes / boundary requirements as we phase out mtrr_add() use.

Lastly hint towards ioremap_uc() for corner cases on device drivers working with devices with mixed regions where MTRR size requirements would otherwise not enable write-combining effective memory types.

Cc Toshi Kani <[email protected]>

Cc Jonathan Corbet <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Suresh Siddha <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Juergen Gross <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Dave Airlie <[email protected]>

Cc Antonino Daplas <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

Cc Tomi Valkeinen <[email protected]>

Cc Ville Syrjälä <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Davidlohr Bueso <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 Documentation/x86/mtrr.txt      | 18 +++++++++++++++---
 Documentation/x86/pat.txt       | 40 +++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/cpu/mtrr/main.c |  3 +++
 3 files changed, 57 insertions(+), 4 deletions(-)

Quoted 5 lines

Documentation/x86/mtrr.txt +0 -0

index cc071dc..a111a6c 100644

Documentation/x86/mtrr.txt line 6

Quoted 9 lines

Documentation/x86/mtrr.txt +5 -3

@@ -1,7 +1,19 @@
 MTRR (Memory Type Range Register) control
-3 Jun 1999
-Richard Gooch
-<[email protected]>
+
+Richard Gooch <[email protected]> - 3 Jun 1999
+Luis R. Rodriguez <[email protected]> - April 9, 2015
+
+=======================================> > +Phasing MTRR use

"Phasing out...".

Tomi,

the new required ioremap_uc() which was added in the initial patch set here is now merged on linux-next but I just noticed a small issue with this atyfb specific patch, I'll fix that and respin and send to you as v5.

From: "Luis R. Rodriguez" <[email protected]>

This series addresses one commend fix on the table for mtrr_add() effect on the PAT case when UC- is used. Other than that it is the same as v4.

Luis R. Rodriguez (6):
x86: add ioremap_uc() - force strong UC, PCD=1, PWT=1
x86: document WC MTRR effects on PAT / non-PAT pages
video: fbdev: atyfb: move framebuffer length fudging to helper
video: fbdev: atyfb: clarify ioremap() base and length used
video: fbdev: atyfb: replace MTRR UC hole with strong UC
video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()

Ville,

the x86 patches are in and on their way to the next version of Linux. Can I trouble you for your review of the atyfb driver changes?

Quoted 4 lines · Luis R. Rodriguez

Ville,

the x86 patches are in and on their way to the next version of Linux. Can I trouble you for your review of the atyfb driver changes?

Hey Ville, just a friendly *poke*.

Quoted 6 lines · Luis R. Rodriguez

Quoted 4 lines · Luis R. Rodriguez

Ville,

the x86 patches are in and on their way to the next version of Linux. Can I trouble you for your review of the atyfb driver changes?

Quoted 1 line

Hey Ville, just a friendly *poke*.

Hey, Ville, trying your Intel address, just in case. Full context of the entire series, in case it helps as this happens to be the more complex of the changes in the entire series:

http://lkml.kernel.org/r/CAB=NE6UgtdSoBsA=8+ueYRAZHDnWUSmQAoHhAaefqudBrSY7Zw@mail.gmail.com

Tomi, Dave, Andy,

Its' been one month now since posting the last unmodified version (other than commit log) of this series [0] and no word or follow up from Ville. The merge window is closing in and other than the PCI changes this would be the last pending series. Can I trouble one of you for your review ? I will note that this series depends on the ioremap_uc() which went in through Ingo's tree and visible on linux-next.

[0] http://lkml.kernel.org/r/[email protected]

Quoted 10 lines · Luis R. Rodriguez

Tomi, Dave, Andy,

Its' been one month now since posting the last unmodified version (other than commit log) of this series [0] and no word or follow up from Ville. The merge window is closing in and other than the PCI changes this would be the last pending series. Can I trouble one of you for your review ? I will note that this series depends on the ioremap_uc() which went in through Ingo's tree and visible on linux-next.

Quoted 1 line

[0] http://lkml.kernel.org/r/[email protected]

Alright, I'll poke to see if Andrew might take these then. I'll post a new clean series just to be crystal clear as this is a complex set, I admit and it may be worth re-iterating things.

Quoted 11 lines · Luis R. Rodriguez

Quoted 10 lines · Luis R. Rodriguez

Tomi, Dave, Andy,

Its' been one month now since posting the last unmodified version (other than commit log) of this series [0] and no word or follow up from Ville. The merge window is closing in and other than the PCI changes this would be the last pending series. Can I trouble one of you for your review ? I will note that this series depends on the ioremap_uc() which went in through Ingo's tree and visible on linux-next.

Quoted 5 lines

Quoted 1 line

[0] http://lkml.kernel.org/r/[email protected]

Alright, I'll poke to see if Andrew might take these then. I'll post a new clean series just to be crystal clear as this is a complex set, I admit and it may be worth re-iterating things.

No, please send it to us against -tip as the previous patches, I'd like all these changes that materially impact x86 to go through the x86 tree.

I can deal with the generic impact.

From: "Luis R. Rodriguez" <[email protected]>

Use pr_info() instead of the old printk to prefix the component where things are coming from. With this readers will know exactly where the message is coming from. Since pr_fmt is already defined in this case we redefine it to "PAT: ".

We leave the users of dprintk() in place, this will print only when the debugpat kernel parameter is enabled. We want to leave those enabled as a debug feature, but also make them use the same prefix.

Cc Andy Walls <[email protected]>

Cc Doug Ledford <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Juergen Gross <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Dave Airlie <[email protected]>

Cc Bjorn Helgaas <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Michael S. Tsirkin <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 arch/x86/mm/pat.c          | 41 +++++++++++++++++++++--------------------
 arch/x86/mm/pat_internal.h |  2 +-
 arch/x86/mm/pat_rbtree.c   |  5 ++++-
 3 files changed, 26 insertions(+), 22 deletions(-)

arch/x86/mm/pat.c +0 -0

index 372ad42..8f88c6a 100644

From: [email protected] [mailto:linux-kernel- [email protected]] On Behalf Of Luis R. Rodriguez
Sent: Thursday, April 30, 2015 3:25 PM
Subject: [PATCH v5 1/6] x86/mm/pat: use pr_info() and friends

arch/x86/mm/pat_rbtree.c +0 -0

Quoted 5 lines

From: [email protected] [mailto:linux-kernel- [email protected]] On Behalf Of Luis R. Rodriguez
Sent: Thursday, April 30, 2015 3:25 PM
Subject: [PATCH v5 1/6] x86/mm/pat: use pr_info() and friends

...

arch/x86/mm/pat.c static int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t *vma_prot, · line 760

Quoted 10 lines

(quoted diff) +0 -1

-			printk(KERN_ERR "%s:%d map pfn expected mapping

type %s"

arch/x86/mm/pat.c +2 -6

-				" for [mem %#010Lx-%#010Lx], got %s\n",
-				current->comm, current->pid,
-				cattr_name(want_pcm),
-				(unsigned long long)paddr,
-				(unsigned long long)(paddr + size - 1),
-				cattr_name(pcm));
+			pr_err("%s:%d map pfn expected mapping type %s"
+			       " for [mem %#010Lx-%#010Lx], got %s\n",

Since the patch joins some other print format strings split across lines (which checkpatch allows), you might want to join this one too.

...

Quoted 1 line

arch/x86/mm/pat_rbtree.c +0 -0

...

arch/x86/mm/pat_rbtree.c success: · line 168

Quoted 5 lines

failure:

arch/x86/mm/pat_rbtree.c +1 -1

-	printk(KERN_INFO "%s:%d conflicting memory types "
+	pr_info("%s:%d conflicting memory types "
 		"%Lx-%Lx %s<->%s\n", current->comm, current->pid, start,
 		end, cattr_name(found_type), cattr_name(match->type));

and that one.