Changes in Makefile

f9aad622 - mm: rename GENERIC_PTDUMP and PTDUMP_CORE

Wed, 26 Feb 2025 12:24:04 +0000

mm: rename GENERIC_PTDUMP and PTDUMP_COREPlatforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.But generic ptdump gets enabled via PTDUMP_CORE. These configscombination is confusing as they sound very similar and does notdifferentiate between platform's feature subscription and featureenablement for ptdump. Rename the configs as ARCH_HAS_PTDUMP and PTDUMPmaking it more clear and improve readability.Link: https://lkml.kernel.org/r/20250226122404.1927473-6-anshuman.khandual@arm.comSigned-off-by: Anshuman Khandual Reviewed-by: Christophe Leroy (powerpc)Acked-by: Catalin Marinas [arm64]Cc: Will Deacon Cc: Jonathan Corbet Cc: Marc Zyngier Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Christophe Leroy Cc: Madhavan Srinivasan Cc: Mark Rutland Cc: Steven Price Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm64/mm/Makefile

fc84bc53 - arm64/gcs: Context switch GCS state for EL0

Tue, 01 Oct 2024 22:59:00 +0000

arm64/gcs: Context switch GCS state for EL0There are two registers controlling the GCS state of EL0, GCSPR_EL0 whichis the current GCS pointer and GCSCRE0_EL1 which has enable bits for thespecific GCS functionality enabled for EL0. Manage these on context switchand process lifetime events, GCS is reset on exec(). Also ensure thatany changes to the GCS memory are visible to other PEs and that changesfrom other PEs are visible on this one by issuing a GCSB DSYNC whenmoving to or from a thread with GCS.Since the current GCS configuration of a thread will be visible touserspace we store the configuration in the format used with userspaceand provide a helper which configures the system register as needed.On systems that support GCS we always allow access to GCSPR_EL0, thisfacilitates reporting of GCS faults if userspace implements disabling ofGCS on error - the GCS can still be discovered and examined even if GCShas been disabled.Reviewed-by: Catalin Marinas Reviewed-by: Thiago Jung Bauermann Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20241001-arm64-gcs-v13-21-222b78d87eee@kernel.orgSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/mm/Makefile

e7bafbf7 - arm64: mm: Add top-level dispatcher for internal mem_encrypt API

Fri, 30 Aug 2024 13:01:46 +0000

arm64: mm: Add top-level dispatcher for internal mem_encrypt APIImplementing the internal mem_encrypt API for arm64 depends entirely onthe Confidential Computing environment in which the kernel is running.Introduce a simple dispatcher so that backend hooks can be registereddepending upon the environment in which the kernel finds itself.Reviewed-by: Catalin Marinas Reviewed-by: Steven Price Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20240830130150.8568-4-will@kernel.orgSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

4602e575 - arm64/mm: wire up PTE_CONT for user mappings

Thu, 15 Feb 2024 10:31:59 +0000

arm64/mm: wire up PTE_CONT for user mappingsWith the ptep API sufficiently refactored, we can now introduce a new"contpte" API layer, which transparently manages the PTE_CONT bit for usermappings.In this initial implementation, only suitable batches of PTEs, set viaset_ptes(), are mapped with the PTE_CONT bit. Any subsequent modificationof individual PTEs will cause an "unfold" operation to repaint the contpteblock as individual PTEs before performing the requested operation. While, a modification of a single PTE could cause the block of PTEs towhich it belongs to become eligible for "folding" into a contpte entry,"folding" is not performed in this initial implementation due to the costsof checking the requirements are met. Due to this, contpte mappings willdegrade back to normal pte mappings over time if/when protections arechanged. This will be solved in a future patch.Since a contpte block only has a single access and dirty bit, the semantichere changes slightly; when getting a pte (e.g. ptep_get()) that is partof a contpte mapping, the access and dirty information are pulled from theblock (so all ptes in the block return the same access/dirty info). Whenchanging the access/dirty info on a pte (e.g. ptep_set_access_flags())that is part of a contpte mapping, this change will affect the wholecontpte block. This is works fine in practice since we guarantee thatonly a single folio is mapped by a contpte block, and the core-mm tracksaccess/dirty information per folio.In order for the public functions, which used to be pure inline, tocontinue to be callable by modules, export all the contpte_* symbols thatare now called by those public inline functions.The feature is enabled/disabled with the ARM64_CONTPTE Kconfig parameterat build time. It defaults to enabled as long as its dependency,TRANSPARENT_HUGEPAGE is also enabled. The core-mm depends uponTRANSPARENT_HUGEPAGE to be able to allocate large folios, so if its notenabled, then there is no chance of meeting the physical contiguityrequirement for contpte mappings.Link: https://lkml.kernel.org/r/20240215103205.2607016-13-ryan.roberts@arm.comSigned-off-by: Ryan Roberts Acked-by: Ard Biesheuvel Tested-by: John Hubbard Acked-by: Mark Rutland Reviewed-by: Catalin Marinas Cc: Alistair Popple Cc: Andrey Ryabinin Cc: Barry Song <21cnbao@gmail.com>Cc: Borislav Petkov (AMD) Cc: Dave Hansen Cc: David Hildenbrand Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Morse Cc: Kefeng Wang Cc: Marc Zyngier Cc: Matthew Wilcox (Oracle) Cc: Thomas Gleixner Cc: Will Deacon Cc: Yang Shi Cc: Zi Yan Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm64/mm/Makefile

b9754776 - arm64: mm: move fixmap code to its own file

Thu, 06 Apr 2023 15:27:58 +0000

arm64: mm: move fixmap code to its own fileOver time, arm64's mm/mmu.c has become increasingly large and painful tonavigate. Move the fixmap code to its own file where it can be understood inisolation.There should be no functional change as a result of this patch.Signed-off-by: Mark Rutland Cc: Anshuman Khandual Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Ryan Roberts Cc: Will Deacon Reviewed-by: Ryan Roberts Link: https://lore.kernel.org/r/20230406152759.4164229-3-mark.rutland@arm.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

788bfdd9 - arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectors

Thu, 30 Sep 2021 14:31:00 +0000

arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectorsUsers of trans_pgd may also need a copy of vector table because it isalso may be overwritten if a linear map can be overwritten.Move setup of EL2 vectors from hibernate to trans_pgd, so it can belater shared with kexec as well.Signed-off-by: Pasha Tatashin Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20210930143113.1502553-3-pasha.tatashin@soleen.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

072e3d96 - arm64: hibernate: move page handling function to new trans_pgd.c

Mon, 25 Jan 2021 19:19:08 +0000

arm64: hibernate: move page handling function to new trans_pgd.cNow, that we abstracted the required functions move them to a new home.Later, we will generalize these function in order to be useful outsideof hibernation.Signed-off-by: Pavel Tatashin Reviewed-by: James Morse Link: https://lore.kernel.org/r/20210125191923.1060122-4-pasha.tatashin@soleen.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

ae3c107c - numa: Move numa implementation to common code

Thu, 19 Nov 2020 00:38:26 +0000

numa: Move numa implementation to common codeARM64 numa implementation is generic enough that RISC-V can reuse thatimplementation with very minor cosmetic changes. This will help bothARM64 and RISC-V in terms of maintanace and feature improvementMove the numa implementation code to common directory so that both ISAscan reuse this. This doesn't introduce any function changes for ARM64.Signed-off-by: Atish Patra Acked-by: Jonathan Cameron Tested-by: Jonathan Cameron Acked-by: Catalin Marinas Signed-off-by: Palmer Dabbelt List of files: /linux-6.15/arch/arm64/mm/Makefile

c048ddf8 - arm64/mm/ptdump: Add address markers for BPF regions

Fri, 04 Sep 2020 08:30:59 +0000

arm64/mm/ptdump: Add address markers for BPF regionsKernel virtual region [BPF_JIT_REGION_START..BPF_JIT_REGION_END] is missingfrom address_markers[], hence relevant page table entries are not displayedwith /sys/kernel/debug/kernel_page_tables. This adds those missing markers.While here, also rename arch/arm64/mm/dump.c which sounds bit ambiguous, asarch/arm64/mm/ptdump.c instead.Signed-off-by: Anshuman Khandual Reviewed-by: Steven Price Cc: Catalin Marinas Cc: Will Deacon Cc: Ard Biesheuvel Cc: Steven Price Cc: Andrew Morton Cc: linux-arm-kernel@lists.infradead.orgCc: linux-kernel@vger.kernel.orgLink: https://lore.kernel.org/r/1599208259-11191-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

36943aba - arm64: mte: Enable swap of tagged pages

Wed, 13 May 2020 15:37:50 +0000

arm64: mte: Enable swap of tagged pagesWhen swapping pages out to disk it is necessary to save any tags thathave been set, and restore when swapping back in. Make use of the newpage flag (PG_ARCH_2, locally named PG_mte_tagged) to identify pageswith tags. When swapping out these pages the tags are stored in memoryand later restored when the pages are brought back in. Because shmem canswap pages back in without restoring the userspace PTE it is alsonecessary to add a hook for shmem.Signed-off-by: Steven Price [catalin.marinas@arm.com: move function prototypes to mte.h][catalin.marinas@arm.com: drop '_tags' from arch_swap_restore_tags()]Signed-off-by: Catalin Marinas Cc: Andrew Morton Cc: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

102f45fd - arm64: mm: convert mm/dump.c to use walk_page_range()

Tue, 04 Feb 2020 01:36:29 +0000

arm64: mm: convert mm/dump.c to use walk_page_range()Now walk_page_range() can walk kernel page tables, we can switch the arm64ptdump code over to using it, simplifying the code.Link: http://lkml.kernel.org/r/20191218162402.45610-22-steven.price@arm.comSigned-off-by: Steven Price Reviewed-by: Catalin Marinas Cc: Albert Ou Cc: Alexandre Ghiti Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Christian Borntraeger Cc: Dave Hansen Cc: David S. Miller Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Hogan Cc: James Morse Cc: Jerome Glisse Cc: "Liang, Kan" Cc: Mark Rutland Cc: Michael Ellerman Cc: Paul Burton Cc: Paul Mackerras Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Ralf Baechle Cc: Russell King Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vineet Gupta Cc: Will Deacon Cc: Zong Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/arm64/mm/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/arch/arm64/mm/Makefile

ec6d06ef - arm64: Add support for CONFIG_DEBUG_VIRTUAL

Tue, 10 Jan 2017 21:35:50 +0000

arm64: Add support for CONFIG_DEBUG_VIRTUALx86 has an option CONFIG_DEBUG_VIRTUAL to do additional checkson virt_to_phys calls. The goal is to catch users who are callingvirt_to_phys on non-linear addresses immediately. This inclues callersusing virt_to_phys on image addresses instead of __pa_symbol. As featuressuch as CONFIG_VMAP_STACK get enabled for arm64, this becomes increasinglyimportant. Add checks to catch bad virt_to_phys usage.Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Laura Abbott Signed-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

4ddb9bf8 - arm64: dump: Make ptdump debugfs a separate option

Thu, 27 Oct 2016 16:27:31 +0000

arm64: dump: Make ptdump debugfs a separate optionptdump_register currently initializes a set of page table information andregisters debugfs. There are uses for the ptdump option without wanting thedebugfs options. Split this out to make it a separate option.Reviewed-by: Ard Biesheuvel Reviewed-by: Kees Cook Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Laura Abbott Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/mm/Makefile

1a2db300 - arm64, numa: Add NUMA support for arm64 platforms.

Fri, 08 Apr 2016 22:50:27 +0000

arm64, numa: Add NUMA support for arm64 platforms.Attempt to get the memory and CPU NUMA node via of_numa. If thatfails, default the dummy NUMA node and map all memory and CPUs to node0.Tested-by: Shannon Zhao Reviewed-by: Robert Richter Signed-off-by: Ganapatrao Kulkarni Signed-off-by: David Daney Signed-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

39d114dd - arm64: add KASAN support

Mon, 12 Oct 2015 15:52:58 +0000

arm64: add KASAN supportThis patch adds arch specific code for kernel address sanitizer(see Documentation/kasan.txt).1/8 of kernel addresses reserved for shadow memory. There was nobig enough hole for this, so virtual addresses for shadow werestolen from vmalloc area.At early boot stage the whole shadow region populated with justone physical page (kasan_zero_page). Later, this page reusedas readonly zero shadow for some memory that KASan currentlydon't track (vmalloc).After mapping the physical memory, pages for shadow memory areallocated and mapped.Functions like memset/memmove/memcpy do a lot of memory accesses.If bad pointer passed to one of these function it is importantto catch this. Compiler's instrumentation cannot do this sincethese functions are written in assembly.KASan replaces memory functions with manually instrumented variants.Original functions declared as weak symbols so strong definitionsin mm/kasan/kasan.c could replace them. Original functions have aliaseswith '__' prefix in name, so we could call non-instrumented variantif needed.Some files built without kasan instrumentation (e.g. mm/slub.c).Original mem* function replaced (via #define) with prefixed variantsto disable memory access checks for such files.Signed-off-by: Andrey Ryabinin Tested-by: Linus Walleij Reviewed-by: Catalin Marinas Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/mm/Makefile

4b59246d - arm64: remove another unnecessary libfdt include path

Mon, 06 Jul 2015 15:08:09 +0000

arm64: remove another unnecessary libfdt include pathPatch 63a4aea55670 ("of: clean-up unnecessary libfdt include paths")removed all explicit libfdt include paths, since those are no longernecessary after the latest dtc upgrade. However, this one snuck induring the same merge window. Remove it.Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/mm/Makefile

61bd93ce - arm64: use fixmap region for permanent FDT mapping

Mon, 01 Jun 2015 11:40:32 +0000

arm64: use fixmap region for permanent FDT mappingCurrently, the FDT blob needs to be in the same 512 MB region asthe kernel, so that it can be mapped into the kernel virtual memoryspace very early on using a minimal set of statically allocatedtranslation tables.Now that we have early fixmap support, we can relax this restriction,by moving the permanent FDT mapping to the fixmap region instead.This way, the FDT blob may be anywhere in memory.This also moves the vetting of the FDT to mmu.c, since the earlyinit code in head.S does not handle mapping of the FDT anymore.At the same time, fix up some comments in head.S that have gone stale.Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Ard Biesheuvel Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/mm/Makefile

c9465b4e - arm64: add support to dump the kernel page tables

Wed, 26 Nov 2014 00:28:39 +0000

arm64: add support to dump the kernel page tablesIn a similar manner to arm, it's useful to be able to dump the pagetables to verify permissions and memory types. Add a debugfs fileto check the page tables.Acked-by: Steve Capper Tested-by: Steve Capper Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Laura Abbott [will: s/BUFFERABLE/NORMAL-NC/]Signed-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile

11d91a77 - arm64: Add CONFIG_DEBUG_SET_MODULE_RONX support

Tue, 19 Aug 2014 19:41:43 +0000

arm64: Add CONFIG_DEBUG_SET_MODULE_RONX supportIn a similar fashion to other architecture, add the infrastructureand Kconfig to enable DEBUG_SET_MODULE_RONX support. Whenenabled, module ranges will be marked read-only/no-execute asappropriate.Signed-off-by: Laura Abbott [will: fixed off-by-one in module end check]Signed-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/mm/Makefile