kernel/git/stable/linux.git/arch/x86/mm/pat.c, branch master

x86/mm/pat: Move the memtype related files to arch/x86/mm/pat/

2019-12-10T09:12:55+00:00

- pat.c offers, dominantly, the memtype APIs - so rename it to memtype.c. - pageattr.c is offering, primarily, the set_memory*() page attribute APIs, which is offered via the header: name the .c file along the same pattern. I.e. perform these renames, and move them all next to each other in arch/x86/mm/pat/: pat.c => memtype.c pat_internal.h => memtype.h pat_interval.c => memtype_interval.c pageattr.c => set_memory.c pageattr-test.c => cpa-test.c Signed-off-by: Ingo Molnar

x86/mm/pat: Clean up PAT initialization flags

2019-12-10T09:12:55+00:00

Right now we have these variables that impact the PAT initialization sequence: pat_disabled boot_cpu_done pat_initialized init_cm_done Some have a pat_ prefix, some not, and the naming is random, which makes their purpose rather opaque. Name them consistently and according to their role: pat_disabled pat_bp_initialized pat_bp_enabled pat_cm_initialized Also rename pat_bsp_init() => pat_bp_init(), to use the canonical abbreviation. Also add a warning for double calls of init_cache_modes(), the call chains leading to this are complex and I couldn't convince myself that we never call this function twice - so utilize the flag for a debug check. No change in functionality intended. Signed-off-by: Ingo Molnar

x86/mm/pat: Harmonize 'struct memtype *' local variable and function parameter use

2019-12-10T09:12:55+00:00

We have quite a zoo of 'struct memtype' variable nomenclature: new entry print_entry data match out memtype Beyond the randomness, some of these are outright confusing, especially when used in larger functions. Standardize them: entry entry_new entry_old entry_print entry_match entry_out Signed-off-by: Ingo Molnar

x86/mm/pat: Simplify the free_memtype() control flow

2019-12-10T09:12:55+00:00

Simplify/streamline the quirky handling of the pat_pagerange_is_ram() logic, and get rid of the 'err' local variable. Signed-off-by: Ingo Molnar

x86/mm/pat: Create fixed width output in /sys/kernel/debug/x86/pat_memtype_list, similar to the E820 debug printouts

2019-12-10T09:12:55+00:00

Before: write-back @ 0xbdfa9000-0xbdfaa000 write-back @ 0xbdfaa000-0xbdfab000 write-back @ 0xbdfab000-0xbdfac000 uncached-minus @ 0xc0000000-0xd0000000 uncached-minus @ 0xd0900000-0xd0920000 uncached-minus @ 0xd0920000-0xd0940000 uncached-minus @ 0xd0940000-0xd0960000 uncached-minus @ 0xd0960000-0xd0980000 uncached-minus @ 0xd0980000-0xd0981000 uncached-minus @ 0xd0990000-0xd0991000 uncached-minus @ 0xd09a0000-0xd09a1000 uncached-minus @ 0xd09b0000-0xd09b1000 uncached-minus @ 0xd0d00000-0xd0d01000 uncached-minus @ 0xd0d10000-0xd0d11000 uncached-minus @ 0xd0d20000-0xd0d21000 uncached-minus @ 0xd0d40000-0xd0d41000 uncached-minus @ 0xfed00000-0xfed01000 uncached-minus @ 0xfed1f000-0xfed20000 uncached-minus @ 0xfed40000-0xfed41000 After: PAT: [mem 0x00000000bdf8e000-0x00000000bdfa8000] write-back PAT: [mem 0x00000000bdfa9000-0x00000000bdfaa000] write-back PAT: [mem 0x00000000bdfaa000-0x00000000bdfab000] write-back PAT: [mem 0x00000000bdfab000-0x00000000bdfac000] write-back PAT: [mem 0x00000000c0000000-0x00000000d0000000] uncached-minus PAT: [mem 0x00000000d0900000-0x00000000d0920000] uncached-minus PAT: [mem 0x00000000d0920000-0x00000000d0940000] uncached-minus PAT: [mem 0x00000000d0940000-0x00000000d0960000] uncached-minus PAT: [mem 0x00000000d0960000-0x00000000d0980000] uncached-minus PAT: [mem 0x00000000d0980000-0x00000000d0981000] uncached-minus PAT: [mem 0x00000000d0990000-0x00000000d0991000] uncached-minus PAT: [mem 0x00000000d09a0000-0x00000000d09a1000] uncached-minus PAT: [mem 0x00000000d09b0000-0x00000000d09b1000] uncached-minus PAT: [mem 0x00000000fed1f000-0x00000000fed20000] uncached-minus PAT: [mem 0x00000000fed40000-0x00000000fed41000] uncached-minus The advantage is that it's easier to parse at a glance - and the tree is ordered by start address, which is now reflected in putting the start address in the first column. This is also now similar to how we print e820 entries: BIOS-e820: [mem 0x00000000bafda000-0x00000000bb3d3fff] usable BIOS-e820: [mem 0x00000000bb3d4000-0x00000000bdd2efff] reserved BIOS-e820: [mem 0x00000000bdd2f000-0x00000000bddccfff] ACPI NVS BIOS-e820: [mem 0x00000000bddcd000-0x00000000bdea0fff] ACPI data BIOS-e820: [mem 0x00000000bdea1000-0x00000000bdf2efff] ACPI NVS Since this is a debugfs file not used by tools there's no known ABI dependencies. Signed-off-by: Ingo Molnar

x86/mm/pat: Disambiguate PAT-disabled boot messages

2019-12-10T09:12:55+00:00

Right now we have these four types of PAT-disabled boot messages: x86/PAT: PAT support disabled. x86/PAT: PAT MSR is 0, disabled. x86/PAT: MTRRs disabled, skipping PAT initialization too. x86/PAT: PAT not supported by CPU. The first message is ambiguous in that it doesn't signal that PAT is off due to a boot option. The second message doesn't really make it clear that this is the MSR value during early bootup and it's the firmware environment that disabled PAT support. The fourth message doesn't really make it clear that we disable PAT support because CONFIG_MTRR is off in the kernel. Clarify, harmonize and fix the spelling in these user-visible messages: x86/PAT: PAT support disabled via boot option. x86/PAT: PAT support disabled by the firmware. x86/PAT: PAT support disabled because CONFIG_MTRR is disabled in the kernel. x86/PAT: PAT not supported by the CPU. Also add a fifth message, in case PAT support is disabled at build time: x86/PAT: PAT support disabled because CONFIG_X86_PAT is disabled in the kernel. Previously we'd just silently return from pat_init() without giving any indication that PAT support is off. Finally, clarify/extend some of the comments related to PAT initialization. Signed-off-by: Ingo Molnar

x86/mm/pat: Update the comments in pat.c and pat_interval.c and refresh the code a bit

2019-12-10T09:12:55+00:00

Tidy up the code: - add comments explaining the PAT code, the role of the functions and the logic - fix various typos and grammar while at it - simplify the file-scope memtype_interval_*() namespace to interval_*() - simplify stylistic complications such as unnecessary linebreaks or convoluted control flow - use the simpler '#ifdef CONFIG_*' pattern instead of '#if defined(CONFIG_*)' pattern - remove the non-idiomatic newline between late_initcall() and its function definition Signed-off-by: Ingo Molnar

x86/mm/pat: Drop the rbt_ prefix from external memtype calls

2019-11-21T17:48:07+00:00

Drop the rbt_memtype_*() call rbt_ prefix, as we no longer use an rbtree directly. Signed-off-by: Davidlohr Bueso Reviewed-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Borislav Petkov Cc: Linus Torvalds Link: https://lkml.kernel.org/r/20191121011601.20611-4-dave@stgolabs.net Signed-off-by: Ingo Molnar

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45+00:00

Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86/mm: Fix decoy address handling vs 32-bit builds

2018-12-12T02:28:20+00:00

A decoy address is used by set_mce_nospec() to update the cache attributes for a page that may contain poison (multi-bit ECC error) while attempting to minimize the possibility of triggering a speculative access to that page. When reserve_memtype() is handling a decoy address it needs to convert it to its real physical alias. The conversion, AND'ing with __PHYSICAL_MASK, is broken for a 32-bit physical mask and reserve_memtype() is passed the last physical page. Gert reports triggering the: BUG_ON(start >= end); ...assertion when running a 32-bit non-PAE build on a platform that has a driver resource at the top of physical memory: BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved Given that the decoy address scheme is only targeted at 64-bit builds and assumes that the top of physical address space is free for use as a decoy address range, simply bypass address sanitization in the 32-bit case. Lastly, there was no need to crash the system when this failure occurred, and no need to crash future systems if the assumptions of decoy addresses are ever violated. Change the BUG_ON() to a WARN() with an error return. Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for...") Reported-by: Gert Robben Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Tested-by: Gert Robben Cc: stable@vger.kernel.org Cc: Andy Shevchenko Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: platform-driver-x86@vger.kernel.org Cc: Link: https://lkml.kernel.org/r/154454337985.789277.12133288391664677775.stgit@dwillia2-desk3.amr.corp.intel.com