similar to: [PATCH RFC 0/4] x86/fixmap: Unify FIXADDR_TOP

On 28.04.23 11:50, Hou Wenlong wrote: > Similar to the alternative patching, use relative reference for original > instruction rather than absolute one, which saves 8 bytes for one entry > on x86_64. And it could generate R_X86_64_PC32 relocation instead of > R_X86_64_64 relocation, which also reduces relocation metadata on > relocatable builds. And the alignment could be hard

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> When NR_CPUS increases the fixmap might need more than the page allocated by head_32.S. This patch introduces the logic to calculate the additional memory that is going to be required by early_ioremap_page_table_range_init: - enough memory to allocate the pte pages needed to cover the fixmap virtual memory range, minus the single

For whatever reasons SH has highmem bits all over the place but does not enable it via Kconfig. Remove the bitrot. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> --- arch/sh/include/asm/fixmap.h | 8 -------- arch/sh/include/asm/kmap_types.h | 15 --------------- arch/sh/mm/init.c | 8 -------- 3 files changed, 31 deletions(-) ---

This most curious patch allows the fixmap on i386 to be unfixed. The = result is that we can create a dynamically sizable hole at the top of = kernel linear address space. I know at least some virtualization = developers are interested in being able to achieve this to achieve = run-time sizing of a hole in which a hypervisor can live, or at least to = test out the performance

This most curious patch allows the fixmap on i386 to be unfixed. The = result is that we can create a dynamically sizable hole at the top of = kernel linear address space. I know at least some virtualization = developers are interested in being able to achieve this to achieve = run-time sizing of a hole in which a hypervisor can live, or at least to = test out the performance

Adopt the map ordering to match the other architectures and the generic code. Also make the maximum entries limited and not dependend on the number of CPUs. With the original implementation did the following calculation: nr_slots = mapsize >> PAGE_SHIFT; The results in either 512 or 1024 total slots depending on configuration. The total slots have to be divided by the number of CPUs to

No reason having the same code in every architecture. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> Cc: Russell King <linux at armlinux.org.uk> Cc: Arnd Bergmann <arnd at arndb.de> Cc: linux-arm-kernel at lists.infradead.org --- V3: Remove the kmap types cruft --- arch/arm/Kconfig | 1 arch/arm/include/asm/fixmap.h | 4 -

Hi, I am a libvirt user , there is a requirement about libvirt : I need a virsh cmd like "#virsh *create-as* --disk --net " to create a very sample guest I have not xml file and I think it's a little hard for me to create a NEW xml for libvirt , so I need a virsh cmd like "vol-create-as " help me do that. I know there are a lot of options for creating a guest , I just need

AFAICT we'll pay one extra TLB entry for this patch. Zach had a patch which left the vsyscall page at the top of memory (minus hole for hypervisor) and patched the ELF header at boot. Thoughts welcome, Rusty. Name: Move vsyscall page out of fixmap, above stack Author: Gerd Hoffmann <kraxel@suse.de> Hypervisors want to use memory at the top of the address space (eg. 64MB for Xen, or

AFAICT we'll pay one extra TLB entry for this patch. Zach had a patch which left the vsyscall page at the top of memory (minus hole for hypervisor) and patched the ELF header at boot. Thoughts welcome, Rusty. Name: Move vsyscall page out of fixmap, above stack Author: Gerd Hoffmann <kraxel@suse.de> Hypervisors want to use memory at the top of the address space (eg. 64MB for Xen, or

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

So, is everyone happy with this smerge of Ingo and Gerd's work? Reposted below. Thanks, Rusty. -------- Forwarded Message -------- From: Linus Torvalds <torvalds@osdl.org> To: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@osdl.org> Subject: Re: [Fwd: [Fwd: FW: argh]] Date: Wed, 17 May 2006 21:35:51 -0700 (PDT) On Thu, 18 May 2006, Rusty Russell wrote: >

The mapping code is odd and looks broken. See FIXME in the comment. Also fix the harmless off by one in the FIX_KMAP_END define. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> Cc: Nick Hu <nickhu at andestech.com> Cc: Greentime Hu <green.hu at gmail.com> Cc: Vincent Chen <deanbo422 at gmail.com> --- V3: Remove the kmap types cruft --- arch/nds32/Kconfig.cpu

The header is not longer used and on alpha, ia64, openrisc, parisc and um it was completely unused anyway as these architectures have no highmem support. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> --- V3: New patch --- arch/alpha/include/asm/kmap_types.h | 15 --------------- arch/ia64/include/asm/kmap_types.h | 13 ------------- arch/openrisc/mm/init.c |

Hi, I hope someone can help point me in the right direction. I have a Sunfire x4100 running Solaris 10x86 06/06 with the Sun Studio 11 compiler. I am just trying to do a stock compile of dovecot-1.0.rc7 Ran the ./configure fine. See Below. Install prefix ...................... : /usr/local File offsets ........................ : 64bit I/O loop method ..................... : poll File change

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner <tglx at linutronix.de> Cc: Thomas Bogendoerfer <tsbogend at alpha.franken.de> Cc: linux-mips at vger.kernel.org --- V3: Remove the kmap types cruft --- arch/mips/Kconfig | 1 arch/mips/include/asm/fixmap.h | 4 - arch/mips/include/asm/highmem.h | 6 +-

No reason having the same code in every architecture Signed-off-by: Thomas Gleixner <tglx at linutronix.de> Cc: Michael Ellerman <mpe at ellerman.id.au> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Paul Mackerras <paulus at samba.org> Cc: linuxppc-dev at lists.ozlabs.org --- V3: Remove the kmap types cruft --- arch/powerpc/Kconfig | 1

On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz at infradead.org> > > wrote: > > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > > > > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote:

On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote: > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > > Minor changes based on feedback and rebase from v10. > > > > Splitting the previous serie in two. This part contains assembly code > > changes required for PIE but without any direct dependencies with the > > rest of the patchset. >

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug