summaryrefslogtreecommitdiff
path: root/scripts/objdiff
diff options
context:
space:
mode:
authorMatthew Wilcox (Oracle) <willy@infradead.org>2023-08-18 21:23:33 +0100
committerAndrew Morton <akpm@linux-foundation.org>2023-08-24 16:20:29 -0700
commit051ddcfeb1bdbae45e660c0db2468d29ca15c6c2 (patch)
tree21cc3df15dac68ee95f1b0ae2246522e1fabde71 /scripts/objdiff
parentbb7dbaafff3f582d18028a5b99a8faa789842678 (diff)
downloadkernel-051ddcfeb1bdbae45e660c0db2468d29ca15c6c2.tar.gz
mm: move PMD_ORDER to pgtable.h
Patch series "Change calling convention for ->huge_fault", v2. There are two unrelated changes to the calling convention for ->huge_fault. I've bundled them together to help people notice the change. The first is to improve scalability of DAX page faults by allowing them to be handled under the VMA lock. The second is to remove enum page_entry_size since it's really unnecessary. The changelogs and documentation updates hopefully work to that end. This patch (of 3): Allow this to be used in generic code. Also add PUD_ORDER. Link: https://lkml.kernel.org/r/20230818202335.2739663-1-willy@infradead.org Link: https://lkml.kernel.org/r/20230818202335.2739663-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'scripts/objdiff')
0 files changed, 0 insertions, 0 deletions
ntent> x86/boot: Disable UBSAN in early boot code 2024-12-05T12:18:54Z Ard Biesheuvel ardb@kernel.org 2024-12-05T11:28:09Z urn:sha1:3b6f99a94b04b389292590840d96342b7dd08941 The early boot code runs from a 1:1 mapping of memory, and may execute before the kernel virtual mapping is even up. This means absolute symbol references cannot be permitted in this code. UBSAN injects references to global data structures into the code, and without -fPIC, those references are emitted as absolute references to kernel virtual addresses. Accessing those will fault before the kernel virtual mapping is up, so UBSAN needs to be disabled in early boot code. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20241205112804.3416920-13-ardb+git@google.com x86/sev: Avoid WARN()s and panic()s in early boot code 2024-12-05T12:18:54Z Ard Biesheuvel ardb@kernel.org 2024-12-05T11:28:06Z urn:sha1:09d35045cd0f4265cf1dfe18ef83285fdc294688 Using WARN() or panic() while executing from the early 1:1 mapping is unlikely to do anything useful: the string literals are passed using their kernel virtual addresses which are not even mapped yet. But even if they were, calling into the printk() machinery from the early 1:1 mapped code is not going to get very far. So drop the WARN()s entirely, and replace panic() with a deadloop. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20241205112804.3416920-10-ardb+git@google.com x86/sev: Move SEV compilation units 2024-07-11T09:55:58Z Borislav Petkov (AMD) bp@alien8.de 2024-06-19T09:03:16Z urn:sha1:38918e0bb2c51c21ea464b071a254b27ff9aa71d A long time ago it was agreed upon that the coco stuff needs to go where it belongs: https://lore.kernel.org/all/Yg5nh1RknPRwIrb8@zn.tnic and not keep it in arch/x86/kernel. TDX did that and SEV can't find time to do so. So lemme do it. If people have trouble converting their ongoing featuritis patches, ask me for a sed script. No functional changes. Move the instrumentation exclusion bits too, as helpfully caught and reported by the 0day folks. Closes: https://lore.kernel.org/oe-kbuild-all/202406220748.hG3qlmDx-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-lkp/202407091342.46d7dbb-oliver.sang@intel.com Reported-by: kernel test robot <oliver.sang@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com> Reviewed-by: Ashish Kalra <ashish.kalra@amd.com> Tested-by: kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/r/20240619093014.17962-1-bp@kernel.org