Re: [PATCH v6 1/5] x86/paravirt: introduce ALT_NOT_XEN

2023-12-10 Thread H. Peter Anvin
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

RE: [PATCH 0/3] x86 disk image and modules initramfs generation

2021-04-20 Thread H. Peter Anvin
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

[PATCH v2 1/3] x86/boot: Modernize genimage script; hdimage support; remove bzlilo

2021-04-19 Thread H. Peter Anvin
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,

[PATCH v2 3/3] x86/boot: Add option to add modules.img to {fd,hd,iso}image

2021-04-19 Thread H. Peter Anvin
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

[PATCH v2 2/3] usr, modules: Add build target for creating a modules initramfs image

2021-04-19 Thread H. Peter Anvin
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

[PATCH 0/3] x86 disk image and modules initramfs generation

2021-04-19 Thread H. Peter Anvin
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 bu

[PATCH 2/3] usr, modules: Add build target for creating a modules initramfs image

2021-04-19 Thread H. Peter Anvin
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

[PATCH 1/3] x86/boot: Modernize genimage script; hdimage support; remove bzlilo

2021-04-19 Thread H. Peter Anvin
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,

[PATCH 0/3] x86 disk image and modules initramfs generation

2021-04-19 Thread H. Peter Anvin
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 bu

[PATCH 3/3] x86/boot: Add option to add modules.img to {fd,hd,iso}image

2021-04-19 Thread H. Peter Anvin
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(-)

Re: [RFC PATCH 1/2] Documentation/admin-guide: README & svga: remove use of "rdev"

2020-08-31 Thread H. Peter Anvin
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

Re: [PATCH] Documentation/x86/boot.rst: minor improvement

2020-08-31 Thread H. Peter Anvin
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

Re: [PATCH] [v2] Documentation: clarify driver licensing rules

2020-08-31 Thread H. Peter Anvin
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

Re: [PATCH v2] x86: Use xorl %0,%0 in __get_user_asm

2020-08-27 Thread H. Peter Anvin
Rewrite 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)

Re: [PATCH] x86: Use XORL r32,r32 in __get_user_asm

2020-08-27 Thread H. Peter Anvin
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

Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on a 64 bit system

2020-08-24 Thread H. Peter Anvin
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

Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

2020-08-20 Thread H. Peter Anvin
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

Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

2020-08-18 Thread H. Peter Anvin
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

Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

2020-08-17 Thread H. Peter Anvin
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

Re: [PATCH 1/4] Makefile: add -fno-builtin-stpcpy

2020-08-17 Thread H. Peter Anvin
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

Re: [PATCH] decompress_bunzip2: fix sizeof type in start_bunzip

2020-07-12 Thread H. Peter Anvin
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'

Re: [PATCH 09/16] initrd: remove the BLKFLSBUF call in handle_initrd

2020-07-02 Thread H. Peter Anvin
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

Re: [PATCH] initrd: Remove erroneous comment

2020-06-22 Thread H. Peter Anvin
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

Re: [PATCH] initrd: Remove erroneous comment

2020-06-22 Thread H. Peter Anvin
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.

Re: umip: AMD Ryzen 3900X, pagefault after emulate SLDT/SIDT instruction

2020-05-19 Thread H. Peter Anvin
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

Re: [PATCH] x86: Use INVPCID mnemonic in invpcid.h

2020-05-08 Thread H. Peter Anvin
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

Re: [PATCH] x86: bitops: fix build regression

2020-05-08 Thread H. Peter Anvin
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: >

Re: [tip: x86/urgent] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h

2019-08-24 Thread H. Peter Anvin
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: >>

Re: [PATCH 1/1] x86/boot: clear some fields explicitly

2019-07-25 Thread H. Peter Anvin
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

Re: [PATCH 1/1] x86/boot: clear some fields explicitly

2019-07-25 Thread H. Peter Anvin
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

Re: [PATCH RFC 1/2] x86/boot: Introduce the setup_header2

2019-06-06 Thread H. Peter Anvin
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_

Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()

2019-05-17 Thread H. Peter Anvin
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:

Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()

2019-05-17 Thread H. Peter Anvin
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,

Re: Potentially missing "memory" clobbers in bitops.h for x86

2019-03-29 Thread H. Peter Anvin
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: Potentially missing "memory" clobbers in bitops.h for x86

2019-03-29 Thread H. Peter Anvin
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

Re: [PATCH v2] tty/serial: Add a serial port simulator

2019-03-28 Thread H. Peter Anvin
Dumb question: this is basically a pty on steroids. Wouldn't this be better done by enhancing the pty devices? -0hpa

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

2019-03-06 Thread H. Peter Anvin
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

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

2019-03-06 Thread H. Peter Anvin
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

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

2019-03-06 Thread H. Peter Anvin
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

Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch

2019-02-20 Thread H. Peter Anvin
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

Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch

2019-02-18 Thread H. Peter Anvin
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 really con

Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch

2019-02-18 Thread H. Peter Anvin
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

Re: [PATCH 17/17] module: Prevent module removal racing with text_poke()

2019-01-17 Thread H. Peter Anvin
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

Re: [PATCH 17/17] module: Prevent module removal racing with text_poke()

2019-01-17 Thread H. Peter Anvin
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.

Re: [PATCH v3 0/6] Static calls

2019-01-14 Thread H. Peter Anvin
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

Re: [PATCH v3 0/6] Static calls

2019-01-14 Thread H. Peter Anvin
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 tr

Re: [PATCH v3 0/6] Static calls

2019-01-14 Thread H. Peter Anvin
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)

Re: [PATCH v3 0/6] Static calls

2019-01-14 Thread H. Peter Anvin
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. Pe

Re: [PATCH v3 0/6] Static calls

2019-01-13 Thread H. Peter Anvin
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 */ > cpum

Re: [PATCH v3 0/6] Static calls

2019-01-13 Thread H. Peter Anvin
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

Re: [PATCH v3 0/6] Static calls

2019-01-10 Thread H. Peter Anvin
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

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

2018-12-03 Thread H. Peter Anvin
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.

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

2018-12-03 Thread H. Peter Anvin
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.

Re: Sleeping in user_access section

2018-11-27 Thread H. Peter Anvin
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

Re: Sleeping in user_access section

2018-11-27 Thread H. Peter Anvin
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

Re: [PATCH] x86/fpu: XRSTOR is expected to raise #GP

2018-11-26 Thread H. Peter Anvin
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

Re: [PATCH] x86/fpu: XRSTOR is expected to raise #GP

2018-11-26 Thread H. Peter Anvin
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

Re: [PATCH v5 02/10] x86/jump_label: Use text_poke_early() during early init

2018-11-20 Thread H. Peter Anvin
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

Re: [PATCH v5 02/10] x86/jump_label: Use text_poke_early() during early init

2018-11-20 Thread H. Peter Anvin
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

Re: [PATCH v5 02/10] x86/jump_label: Use text_poke_early() during early init

2018-11-20 Thread H. Peter Anvin
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. >

Re: [PATCH v5 02/10] x86/jump_label: Use text_poke_early() during early init

2018-11-20 Thread H. Peter Anvin
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. >

Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-19 Thread H. Peter Anvin
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

Re: [PATCH] x86/TSC: Use RDTSCP

2018-11-19 Thread H. Peter Anvin
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

Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

2018-11-11 Thread H. Peter Anvin
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

Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

2018-11-11 Thread H. Peter Anvin
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

Re: [PATCH 2/2] x86/ldt: Unmap PTEs for the slow before freeing LDT

2018-10-24 Thread H. Peter Anvin
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

Re: [PATCH 2/2] x86/ldt: Unmap PTEs for the slow before freeing LDT

2018-10-24 Thread H. Peter Anvin
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

Re: [PATCH stable v2 1/2] termios, tty/tty_baudrate.c: fix buffer overrun

2018-10-23 Thread H. Peter Anvin
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

Re: [PATCH stable v2 1/2] termios, tty/tty_baudrate.c: fix buffer overrun

2018-10-23 Thread H. Peter Anvin
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

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

2018-10-23 Thread H. Peter Anvin
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

Re: [PATCH RFC] x86: Don't include '-Wa,-' when building with Clang

2018-10-23 Thread H. Peter Anvin
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

Re: [PATCH] kvm/x86 : avoid shifting signed 32-bit value by 31 bits

2018-10-15 Thread H. Peter Anvin
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

Re: [PATCH] kvm/x86 : avoid shifting signed 32-bit value by 31 bits

2018-10-15 Thread H. Peter Anvin
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

Re: [PATCH] kvm/x86 : avoid shifting signed 32-bit value by 31 bits

2018-10-15 Thread H. Peter Anvin
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

Re: [PATCH] kvm/x86 : avoid shifting signed 32-bit value by 31 bits

2018-10-15 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-11 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-11 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-11 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-11 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-09 Thread H. Peter Anvin
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

Re: Insanely high baud rates

2018-10-09 Thread H. Peter Anvin
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

Insanely high baud rates

2018-10-09 Thread H. Peter Anvin
[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

Insanely high baud rates

2018-10-09 Thread H. Peter Anvin
[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

Re: [PATCH stable v2 1/2] arch/alpha, termios: implement BOTHER, IBSHIFT and termios2

2018-10-08 Thread H. Peter Anvin
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

Re: [PATCH stable v2 1/2] arch/alpha, termios: implement BOTHER, IBSHIFT and termios2

2018-10-08 Thread H. Peter Anvin
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

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

2018-10-04 Thread H. Peter Anvin
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

Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

2018-10-04 Thread H. Peter Anvin
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

Re: [PATCH 5/5] arch/xtensa, termios: use

2018-10-04 Thread H. Peter Anvin
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

Re: [PATCH 5/5] arch/xtensa, termios: use

2018-10-04 Thread H. Peter Anvin
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

[PATCH 3/5] arch/mips, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 3/5] arch/mips, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 5/5] arch/xtensa, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 0/5] termios: remove arch redundancy in

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 1/5] asm-generic, termios: add alias constants from MIPS

2018-10-04 Thread H. Peter Anvin (Intel)
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-kernel

[PATCH 1/5] asm-generic, termios: add alias constants from MIPS

2018-10-04 Thread H. Peter Anvin (Intel)
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-kernel

[PATCH 5/5] arch/xtensa, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 0/5] termios: remove arch redundancy in

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 2/5] arch/ia64, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 2/5] arch/ia64, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

[PATCH 4/5] arch/parisc, termios: use

2018-10-04 Thread H. Peter Anvin (Intel)
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

  1   2   3   4   5   6   7   8   9   10   >