On December 9, 2023 10:21:34 PM PST, Juergen Gross wrote:
>Introduce the macro ALT_NOT_XEN as a short form of
>ALT_NOT(X86_FEATURE_XENPV).
>
>Suggested-by: Peter Zijlstra (Intel)
>Signed-off-by: Juergen Gross
>---
>V3:
>- split off from next patch
>V5:
>- move patch to the start of the series (B
ovide a *general* solution that fits all
distributions × all boot scenarios.
On April 20, 2021 1:30:07 AM PDT, David Laight wrote:
>From: H. Peter Anvin
>> Sent: 20 April 2021 00:03
>>
>> When compiling on a different machine than the runtime target,
>> including but not li
From: "H. Peter Anvin (Intel)"
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target,
From: "H. Peter Anvin (Intel)"
Make it easy to generate a disk image which includes the all-modules
initramfs image.
Signed-off-by: H. Peter Anvin (Intel)
---
arch/x86/Makefile | 3 ++-
arch/x86/boot/Makefile | 20
2 files changed, 18 insertions(+), 5
From: "H. Peter Anvin (Intel)"
Some distributions really cannot be booted without modules
anymore. To allow an externally built kernel to be run, it is handy to
be able to create an initramfs image with all the modules, that can
appended to an existing initramfs image (preferrably w
From: "H. Peter Anvin" (Intel)
When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.
This adds a build
From: "H. Peter Anvin" (Intel)
Some distributions really cannot be booted without modules
anymore. To allow an externally built kernel to be run, it is handy to
be able to create an initramfs image with all the modules, that can
appended to an existing initramfs image (preferrably w
From: "H. Peter Anvin" (Intel)
The image generation scripts in arch/x86/boot are pretty out of date,
except for the isoimage target. Update and clean up the
genimage.sh script, and make it support an arbitrary number of
initramfs files in the image.
Add a "hdimage" target,
From: "H. Peter Anvin" (Intel)
When compiling on a different machine than the runtime target,
including but not limited to simulators, it is rather handy to be able
to produce a bootable image. The scripts for that in x86 are
relatively old, and assume a BIOS system.
This adds a build
From: "H. Peter Anvin" (Intel)
Make it easy to generate a disk image which includes the all-modules
initramfs image.
Signed-off-by: H. Peter Anvin (Intel)
---
arch/x86/Makefile | 3 ++-
arch/x86/boot/Makefile | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
On 2020-08-31 22:38, Randy Dunlap wrote:
>
> --- linux-next-20200828.orig/Documentation/admin-guide/svga.rst
> +++ linux-next-20200828/Documentation/admin-guide/svga.rst
> @@ -12,7 +12,7 @@ Intro
> This small document describes the "Video Mode Selection" feature which
> allows the use of variou
If you are going to fix the language...
On 2020-08-31 22:25, Cao jin wrote:
> Sorry, I mis-copied 2 addresses. make sure they are CCed.
>
> On 9/1/20 11:41 AM, Cao jin wrote:
>> Typo fix & file name update
>>
>> Signed-off-by: Cao jin
>> ---
>> Documentation/x86/boot.rst | 4 ++--
>> 1 file cha
On 2020-08-14 07:56, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Greg has challenged some recent driver submitters on their license
> choices. He was correct to do so, as the choices in these instances
> did not always advance the aims of the submitters.
>
> But, this left submitters (and the
rite commit message.
>
> Signed-off-by: Uros Bizjak
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
Reviewed-by: H. Peter Anvin (Intel)
On 2020-08-27 09:49, Uros Bizjak wrote:
> Use XORL r32,r32 for all operand sizes. x86_64 zero extends 32bit
> operations, so for 64bit operands, XORL r32,r32 is functionally
> equal to XORL r64,r64, but avoids a REX prefix byte when legacy
> registers are used.
Please make it clear that this refer
On 2020-08-24 14:10, Andy Lutomirski wrote:
>
> PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
>
> PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base accordingly.
>
> PTRACE_READ_SEGMENT_BASE: pass in a segment selector, get a base out.
> You would use this to popula
On 2020-08-18 13:58, Nick Desaulniers wrote:
> On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers
> wrote:
>>
>> On Tue, Aug 18, 2020 at 1:24 PM Arvind Sankar wrote:
>>>
>>> On Tue, Aug 18, 2020 at 12:13:22PM -0700, Linus Torvalds wrote:
>>>> On Tue
On 2020-08-18 10:56, Nick Desaulniers wrote:
>>
>> The problem here is twofold:
>>
>> 1. The user would be expected to know what kind of the optimizations the
>> compiler can do on what function, which is private knowledge to the
>> compiler.
>>
>> 2. The only way to override -fno-builtin is by a h
On 2020-08-17 15:02, Nick Desaulniers wrote:
> -ffreestanding typically inhibits "libcall optimizations" where calls to
> certain library functions can be replaced by the compiler in certain
> cases to calls to other library functions that may be more efficient.
> This can be problematic for embedd
On 2020-08-17 15:02, Nick Desaulniers wrote:
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings. This optimizati
On 2020-07-12 05:59, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis flags this error
>
> lib/decompress_bunzip2.c:671:13: warning: Result of 'malloc' is converted
> to a pointer of type 'unsigned int', which is incompatible with sizeof
> operand type 'int' [unix.MallocSizeo
On 2020-06-15 05:53, Christoph Hellwig wrote:
> BLKFLSBUF used to be overloaded for the ramdisk driver to free the whole
> ramdisk, which was completely different behavior compared to all other
> drivers. But this magic overload got removed in commit ff26956875c2
> ("brd: remove support for BLKFLS
On 2020-06-22 14:01, Tom Rini wrote:
>
> I'm picky here because, well, there's a whole lot of moving parts in the
> pre-kernel world. In a strict sense, "UEFI" doesn't do anything with
> the kernel but based on hpa's comments I assume that at least the
> in-kernel UEFI stub does what Documentatio
On 2020-06-22 13:40, Tom Rini wrote:
> On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
>
>> The other thing you ought to consider fixing:
>> initrd is documented as follows:
>>
>> initrd= [BOOT] Specify the location of the initial ramdisk
>>
>> for bootloaders only.
>>
On 2020-05-19 07:38, Andreas Rammhold wrote:
> Hi,
>
> I've been running into a weird problem with UMIP on a current Ryzen
> 3900x with kernel 5.6.11 where a process receives a page fault after the
> kernel handled the SLDT (or SIDT) instruction (emulation).
>
> The program I am running is run th
Reviewed-by: H. Peter Anvin (Intel)
On 2020-05-08 02:22, Uros Bizjak wrote:
> Current minimum required version of binutils is 2.23,
> which supports INVPCID instruction mnemonic.
>
> Replace the byte-wise specification of INVPCID with
> this proper mnemonic.
>
> Signe
On 2020-05-08 10:21, Nick Desaulniers wrote:
>>
>> One last suggestion. Add the "b" modifier to the mask operand: "orb
>> %b1, %0". That forces the compiler to use the 8-bit register name
>> instead of trying to deduce the width from the input.
>
> Ah right:
> https://gcc.gnu.org/onlinedocs/gcc
On 8/24/19 11:19 AM, Pavel Machek wrote:
> On Fri 2019-08-23 01:10:49, tip-bot2 for Tom Lendacky wrote:
>> The following commit has been merged into the x86/urgent branch of tip:
>>
>> Commit-ID: c49a0a80137c7ca7d6ced4c812c9e07a949f6f24
>> Gitweb:
>> https://git.kernel.org/tip/c49a0a801
On 7/25/19 3:03 PM, Thomas Gleixner wrote:
> On Thu, 25 Jul 2019, h...@zytor.com wrote:
>> On July 25, 2019 2:48:30 PM PDT, Thomas Gleixner wrote:
>>>
>>> But seriously I think it's not completely insane what they are doing
>>> and the table based approach is definitely more readable and maintaina
On 7/25/19 12:22 AM, Thomas Gleixner wrote:
>>
>> The problem with this is that it will break silently when changes are
>> made to this structure.
>
> That's not really the worst problem. Changes to that struct which touch any
> of the to be cleared ranges will break anyway if not handled correctl
to the boot loader.
>
> Suggested-by: H. Peter Anvin
> Signed-off-by: Daniel Kiper
> Reviewed-by: Ross Philipson
> Reviewed-by: Eric Snowberg
> ---
> I know that setup_header2 is not the best name. There were some
> alternatives proposed like setup_header_extra, setup_
On 5/17/19 2:02 PM, Arvind Sankar wrote:
> On Fri, May 17, 2019 at 01:18:11PM -0700, h...@zytor.com wrote:
>>
>> Ok... I just realized this does not work for a modular initramfs, composed
>> at load time from multiple files, which is a very real problem. Should be
>> easy enough to deal with: ins
On 5/17/19 1:18 PM, h...@zytor.com wrote:
>
> Ok... I just realized this does not work for a modular initramfs, composed at
> load time from multiple files, which is a very real problem. Should be easy
> enough to deal with: instead of one large file, use one companion file per
> source file, p
On 3/29/19 2:09 PM, Paul E. McKenney wrote:
>>
>> Note: the atomic versions of these functions obviously need to have
>> "volatile" and the clobber anyway, as they are by definition barriers
>> and moving memory operations around them would be a very serious error.
>
> The atomic functions that re
On 3/29/19 8:54 AM, Alexander Potapenko wrote:
>
>> Of course, this would force the compiler to actually compute the
>> offset, which would slow things down. I have no idea whether this
>> would be better or worse than just using the "memory" clobber.
> Just adding the "memory" clobber to clear_b
Dumb question: this is basically a pty on steroids. Wouldn't this be
better done by enhancing the pty devices?
-0hpa
On 3/6/19 3:37 PM, Daniel Colascione wrote:
>
> I just don't get the opposition to Joel's work. The rest of the thread
> already goes into detail about the problems with pure-filesystem
> solutions, and you and others are just totally ignoring those
> well-thought-out rationales for the module app
On 3/6/19 3:37 PM, Daniel Colascione wrote:
>
> I just don't get the opposition to Joel's work. The rest of the thread
> already goes into detail about the problems with pure-filesystem
> solutions, and you and others are just totally ignoring those
> well-thought-out rationales for the module app
On 3/6/19 3:09 PM, Pavel Machek wrote:
> On Fri 2019-01-18 17:55:43, Joel Fernandes wrote:
>> From: "Joel Fernandes (Google)"
>>
>> Introduce in-kernel headers and other artifacts which are made available
>> as an archive through proc (/proc/kheaders.tgz file). This archive makes
>> it possible to
On 2/19/19 4:48 AM, Will Deacon wrote:
>
> I think you'll still hate this, but could we not disable preemption during
> the uaccess-enabled region, re-enabling it on the fault path after we've
> toggled uaccess off and disable it again when we return back to the
> uaccess-enabled region? Doesn't h
On 2/18/19 6:20 PM, Andy Lutomirski wrote:
>
>
>> On Feb 18, 2019, at 4:24 PM, Linus Torvalds
>> wrote:
>>
>>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin wrote:
>>>
>>> The question is what "fix it" means. I'm reall
On 2/16/19 2:30 AM, Peter Zijlstra wrote:
> On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
>> This implies we invoke schedule -- a restricted operation (consider
>> may_sleep) during execution of STAC-enabled code, but *not* as an
>> exception or interrupt, since those preserve the
On 1/16/19 11:54 PM, Masami Hiramatsu wrote:
> On Wed, 16 Jan 2019 16:32:59 -0800
> Rick Edgecombe wrote:
>
>> From: Nadav Amit
>>
>> It seems dangerous to allow code modifications to take place
>> concurrently with module unloading. So take the text_mutex while the
>> memory of the module is fr
On 1/17/19 10:07 AM, Nadav Amit wrote:
>> On Jan 16, 2019, at 11:54 PM, Masami Hiramatsu wrote:
>>
>> On Wed, 16 Jan 2019 16:32:59 -0800
>> Rick Edgecombe wrote:
>>
>>> From: Nadav Amit
>>>
>>> It seems dangerous to allow code modifications to take place
>>> concurrently with module unloading. S
On 1/14/19 9:01 PM, H. Peter Anvin wrote:
>
> This could be as simple as spinning for a limited time waiting for
> states 0 or 3 if we are not the patching CPU. It is also not necessary
> to wait for the mask to become zero for the first sync if we find
> ourselves suddenly in
On 1/14/19 7:05 PM, Andy Lutomirski wrote:
> On Mon, Jan 14, 2019 at 2:55 PM H. Peter Anvin wrote:
>>
>> I think this sequence ought to work (keep in mind we are already under a
>> mutex, so the global data is safe even if we are preempted):
>
> I'm trying t
I think this sequence ought to work (keep in mind we are already under a
mutex, so the global data is safe even if we are preempted):
set up page table entries
invlpg
set up bp patching global data
cpu = get_cpu()
bp_old_value = atomic_read(bp_write_addr)
do that, and we still have to deal
with #MC and what not.)
The fundamental problem here is that we don't see the #BP on the
patching processor, in which case we could simply complete the patching
from the #BP handler on that processor.
On 1/13/19 6:40 PM, H. Peter Anvin wrote:
>
On 1/13/19 6:31 PM, H. Peter Anvin wrote:
>
> static cpumask_t text_poke_cpumask;
>
> static void text_poke_sync(void)
> {
> smp_wmb();
> text_poke_cpumask = cpu_online_mask;
> smp_wmb(); /* Should be optional on x86 */
> cpumask_c
On 1/11/19 11:39 AM, Jiri Kosina wrote:
> On Fri, 11 Jan 2019, h...@zytor.com wrote:
>
>> I still don't see why can't simply spin in the #BP handler until the
>> patch is complete.
>
> I think this brings us to the already discussed possible deadlock, when
> one CPU#0 is in the middle of text_p
On 1/10/19 9:31 AM, Linus Torvalds wrote:
> On Wed, Jan 9, 2019 at 2:59 PM Josh Poimboeuf wrote:
>>
>> NOTE: At least experimentally, the call destination writes seem to be
>> atomic with respect to instruction fetching. On Nehalem I can easily
>> trigger crashes when writing a call destination a
On 12/3/18 9:32 PM, Juergen Gross wrote:
>
> I'd like to send a followup patch doing that. And I'd like to not only
> test sentinel for being non-zero, but all padding fields as well. This
> should be 4.21 material, though.
>
No, you can't do that. That breaks backwards compatibility.
On 11/23/18 3:57 AM, Julien Thierry wrote:
>
> On x86, the EFLAGS.AC bit is also saved upon exception and I think it is
> cleared upon exception entry so there is implicit exit from the
> user_access mode when taking exception/interrupt.
>
No, it is restored, not cleared.
In summary: on excepti
On 11/26/18 9:49 AM, Sebastian Andrzej Siewior wrote:
> On 2018-11-26 18:27:06 [+0100], Jann Horn wrote:
>> commit 75045f77f7a7 ("x86/extable: Introduce _ASM_EXTABLE_UA for uaccess
>> fixups") incorrectly replaced the fixup entry for XSTATE_OP with a
>> user-#PF-only fixup. However, XRSTOR can also
On 11/20/18 10:18 AM, Peter Zijlstra wrote:
>>
>> Can't we make this test in text_poke() directly, please?
>
> He does that in 9/10 iirc.
>
No, in 9/10 he does that change locally for the jump_label, but there is
absolutely no reason not to do that test in text_poke() proper, and
simply use text
On 11/13/18 5:07 AM, Nadav Amit wrote:
> There is no apparent reason not to use text_poke_early() while we are
> during early-init and we do not patch code that might be on the stack
> (i.e., we'll return to the middle of the patched code). This appears to
> be the case of jump-labels, so do so.
>
On 11/19/18 11:52 AM, Andy Lutomirski wrote:
>
> I thought I benchmarked this on Intel at some point and found the
> LFENCE;RDTSC variant to be slightly faster. But I believe you, so:
>
> Acked-by: Andy Lutomirski
>
As long as the difference isn't significant, the simplicity would seem to be
On 11/10/18 1:03 AM, Juergen Gross wrote:
>
> How would that help? The garabge data written could have the correct
> terminal sentinel value by chance.
>
> That's why I re-used an existing field in setup_header (the version) to
> let grub tell the kernel which part of setup_header was written by
On 10/23/18 9:31 AM, Kirill A. Shutemov wrote:
>
> It shouldn't be a particularly hot path anyway.
>
That's putting it mildly.
-hpa
On 10/23/18 09:02, h...@zytor.com wrote:
>>
>> As I think Al's big termios cleanups are going to be hitting Linus's
>> tree soon, do you know how these patches interact with that?
>>
>> This patch seems like it will not, so I'll be glad to queue that up
>> after my first round of patches get merged
On 10/23/18 11:40, Nick Desaulniers wrote:
> On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
>>
>> at 5:37 PM, Nathan Chancellor wrote:
>>
>> Commit 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in
>> inline assembly code to work around asm() related GCC inlining bugs")
>> added thi
On 10/15/18 10:23 AM, Paolo Bonzini wrote:
>
> Even for a value from a 32-bit register? That would be _BIT, which
> doesn't exist.
>
Just use _BITUL(). gcc is smart enough to know that that the resulting value
is representable in 32 bits.
Or if you really care, submit a patch to create _BITU()
On 10/7/18 6:04 PM, peng.h...@zte.com.cn wrote:
\>
> #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK(0xFF)
> -#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1 << 31)
> +#define AVIC_LOGICAL_ID_ENTRY_VALID_MASK(1UL << 31)
>>>
It is reasonable to change to unsi
On 10/11/18 2:40 PM, Theodore Y. Ts'o wrote:
> On Thu, Oct 11, 2018 at 07:14:30AM -0700, h...@zytor.com wrote:
>>>
>>> I mean - what is the baud rate of a pty ?
>>
>> Whatever the master wants it to be...
>
> I think Alan's point is that it is highly unlikely you would be able
> to push the equiv
On 10/11/18 12:36 PM, Craig Milo Rogers wrote:
> On 18.10.11, Alan Cox wrote:
>> I mean - what is the baud rate of a pty ?
>
> Solaris made the distinction between B0, which means pty hangup mode,
> and any other baud rate:
>
> https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html
>
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in glibc,
>> the question came up if we will ever care about b
[Resending to a wider audience]
In trying to get the termios2 interface actually implemented in glibc,
the question came up if we will ever care about baud rates in excess of
4 Gbps, even in the relatively remote future.
If this is something we care about *at all*, I would like to suggest
that ra
On 10/8/18 8:38 AM, Johan Hovold wrote:
> On Sun, Oct 07, 2018 at 09:06:19PM -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
>> using arbitrary flags. Because BOTHER
On 10/04/18 13:29, Andy Lutomirski wrote:
>>
>> Wonderful.
>>
>> Here is the horrible code I mentioned yesterday. This is about
>> implementing the immediate-patching framework that Linus and others have
>> discussed (it helps both performance and kernel hardening):
>>
>
> I'm wondering if a prod
On 10/04/18 15:35, Max Filippov wrote:
>
> Looks good. But why not removing the header entirely and adding
> generic-y += termbits.h
> to arch/xtensa/include/uapi/asm/Kbuild?
>
Good idea. Should do that for others that also have the same #include.
-hpa
The MIPS definition of termbits.h is almost identical to the generic
one, so use the generic one and only redefine a handful of constants.
Move TIOCSER_TEMT to ioctls.h where it lives for all other
architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James
Some architectures, in this case MIPS, need a couple of legacy alias
constants for bits. There really is no reason why we can't define them
generically for all architectures.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
linux-k
The Xtensa definition of termbits.h is identical to the generic one.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Chris Zankel
Cc: Max Filippov
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Kate Stewart
Cc:
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
arch/xtensa
changed, 27 insertions(+), 824 deletions(-)
Signed-off-by: H. Peter Anvin (Intel)
Cc: "James E.J. Bottomley"
Cc: Arnd Bergmann
Cc: Chris Zankel
Cc: Fenghua Yu
Cc: Greg Kroah-Hartman
Cc: Helge Deller
Cc: James Hogan
Cc: Jiri Slaby
Cc: Kate Stewart
Cc: Max Filippov
Cc: Paul
The IA64 definition of termbits.h is identical to the generic.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Kate Stewart
Cc: Philippe Ombredanne
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc:
Cc: Greg Kroah-Hartman
CC: Jiri Slaby
---
arch/ia64/include/uapi/asm
The PARISC definition of termbits.h is almost identical to the generic
one, so use the generic one and only redefine a handful of constants.
Signed-off-by: H. Peter Anvin (Intel)
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Philippe Ombr
On 10/04/18 13:05, Nadav Amit wrote:
>
> Funny. Immediate-patching is what I was playing with when I encountered the
> gcc issue. Performance got worse instead of improving (or at least staying
> the same), because inlining got crazy.
>
> Anyhow, wait for my soon-to-be-sent RFC in which I define
On 10/04/18 02:16, Ingo Molnar wrote:
>
> * h...@zytor.com wrote:
>
>> Ingo: I wasn't talking necessarily about the specifics of each bit, but
>> rather the general
>> concept about being able to use macros in inlines...
>
> Ok, agreed about that part - and some of the patches did improve rea
On 09/27/18 13:47, ndesaulni...@google.com wrote:
> Early prototypes of Clang with asm goto support produce 6 instances of
> the following warning:
>
> In file included from arch/x86/boot/compressed/misc.h:20:
> In file included from ./include/linux/elf.h:5:
> In file included from ./arch/x86/incl
On 09/26/18 02:08, Borislav Petkov wrote:
> On Tue, Sep 25, 2018 at 02:13:16PM -0700, Nick Desaulniers wrote:
>> Orthogonally, do you know *why* this Makefile overwrites
>> KBUILD_CFLAGS? We take great care to set various compiler flags in
>> the top level Makefile, so to reset them lower in the t
On 09/03/18 20:44, Baoquan He wrote:
>
> 1) in arch/x86/kernel/relocate_kernel_64.S, we set X86_CR4_LA57 into cr4
> if the 1st kernel is in 5-level mode. Then in
> arch/x86/boot/compressed/head_64.S, paging_prepare() is called to decide
> if 5-level mode will be enabled, and prepare the trampoline
On 07/12/18 13:37, Alistair Strachan wrote:
> On Thu, Jul 12, 2018 at 1:25 PM H. Peter Anvin wrote:
>> On 07/12/18 13:10, Alistair Strachan wrote:
>>> The vdso{32,64}.so can fail to link with CC=clang when clang tries to
>>> find a suitable GCC toolchain to link these l
On 07/12/18 13:10, Alistair Strachan wrote:
> The vdso{32,64}.so can fail to link with CC=clang when clang tries to
> find a suitable GCC toolchain to link these libraries with.
>
> /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
> access beyond end of merged section (782)
>
> This happens b
Commit-ID: 0e2e160033283e20f688d8bad5b89460cc5bfcc4
Gitweb: https://git.kernel.org/tip/0e2e160033283e20f688d8bad5b89460cc5bfcc4
Author: H. Peter Anvin
AuthorDate: Thu, 21 Jun 2018 09:23:23 -0700
Committer: Ingo Molnar
CommitDate: Tue, 3 Jul 2018 10:56:27 +0200
x86/asm: Add _ASM_ARG
On 06/25/18 08:40, Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Andy Lutomirski wrote:
>
>> On Fri, Jun 22, 2018 at 11:02 AM Bae, Chang Seok
>> wrote:
>>>
Still setup_cpu_number() sucks.
>>>
>>> How about setup_cpu_and_node_number()?
>>
>> setup_fast_cpu_node_nr()? setup_cpunr_regs()? I d
On 06/22/18 07:24, Andy Lutomirski wrote:
>
> That RPL3 part is false. The following program does:
>
> #include
>
> int main()
> {
> unsigned short sel;
> asm volatile ("mov %%ss, %0" : "=rm" (sel));
> sel &= ~3;
> printf("Will write 0x%hx to GS\n", sel);
> asm volatile ("m
From: "H. Peter Anvin"
It is not only %ds and %es which contain cached user descriptor
information, %fs and %gs do as well.
To make sure we don't do something stupid that will affect processes
which wouldn't want this requalification, be more restrictive about
which sele
From: "H. Peter Anvin"
There is no point in having two different sizes for the "default ldt";
a concept which is obsolete anyway. Since this is kernel-dependent
and not user-space dependent, a 32-bit app needs to be able to accept
the 64-bit value anyway, so use that value,
From: "H. Peter Anvin"
This is generic code which is potentially useful in other contexts.
Unfortunately modify_ldt() is kind of stupid in that it returns a
descriptor in CPU format but takes a different format, but regsets
*have* to operate differently.
Signed-off-by: H. Peter An
From: "H. Peter Anvin"
Give a debugger access to the visible part of the GDT and LDT. This
allows a debugger to find out what a particular segment descriptor
corresponds to; e.g. if %cs is 16, 32, or 64 bits.
v3:
Requalify LDT segments for selectors that have actually ch
From: "H. Peter Anvin"
Provide ptrace/regset access to the LDT, if one exists. This
interface provides both read and write access. The write code is
unified with modify_ldt(); the read code doesn't have enough
similarity so it has been kept made separate.
Signed-off-by: H. Pet
From: "H. Peter Anvin"
We don't want to advertise to user space how many slots the kernel
GDT has, but user space can trivially find out what the last
user-accessible GDT slot is. Add a #define for that so we can use
that in sizing a regset.
Signed-off-by: H. Peter Anvin (I
From: "H. Peter Anvin"
Instead of using X86_32 || IA32_EMULATION, which is really rather ugly
in the Makefile especially, create a dedicated config symbol for the
TLS area. This will be further used in subsequent patches.
Signed-off-by: H. Peter Anvin (Intel)
Cc: Ingo Molnar
From: "H. Peter Anvin"
Provide access to the user-visible part of the GDT via a regset in
ptrace(). Note that we already provide a regset for the TLS area part
of the GDT; these can trivially be unified by looking at the contents
of the regset structure, especially since the TLS a
On 06/12/18 14:24, Dmitry Safonov wrote:
>>
>> Move align_vdso_addr() after get_unmapped_area() to make sure that
>> errata for AMD 15h is always applied.
>
> Alternative dirty-hacky idea:
> specify some (struct file*) to get_unmapped_area() for vdso vma, then
> mapping would be automatically alig
On 06/06/18 18:45, Leizhen (ThunderTown) wrote:
>>
>> The use of signals without SA_RESTORER is considered obsolete, but it's
>> somewhat surprising that the vdso isn't there; it should be mapped even for
>> static binaries esp. on i386 since it is the preferred way to do system
>> calls (you do
On 06/04/18 20:57, Mika Penttilä wrote:
>
> This won't work on X86-32 because it actually uses the segment limit with fs:
> access. So there
> is a reason why the lsl based method is X86-64 only.
>
Why does that matter in any shape, way, or form? The LSL instruction
doesn't touch any of the
On 05/25/18 13:36, Nick Desaulniers wrote:
> On Fri, May 25, 2018 at 10:56 AM wrote:
>> You need the extern inline in the .h file and the out-of-line .S file
> both.
>
> But the out-of-line .S file looks like:
>
> ...
> 10 ENTRY(native_save_fl)
>
> 11 pushf
>
> 12 pop %_ASM_AX
On 05/24/18 13:26, Nick Desaulniers wrote:
>
> Considering the bigger picture is why we have this thread going. You have
> much more context about the kernel than I or the llvm maintainers do. We
> can't consider the bigger picture until we ask.
>
And this is correct. However, *every* LLVM req
On 05/24/18 14:27, Nick Desaulniers wrote:
> https://godbolt.org/g/oku8ux
>
> Is there a more canonical way the kernel does feature detection that looks
> better than:
>
Hm. I though we had, but it doesn't seem so. For cc we only seem to be
able to detect flags. For as we have rules that can det
1 - 100 of 5864 matches
Mail list logo
