[PATCH] selftests: use "$(MAKE)" instead of "make" for headers_install

If top make invocation uses -j4 or larger, this patch reduces "make headers_install" subtask run time from 30 to 7 seconds. CC: Shuah Khan CC: Shuah Khan CC: linux-kselft...@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Denys Vlasenko --- tools/testing/selftests/

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On 4/8/19 4:57 PM, Sedat Dilek wrote: We have arch/x86/crypto/chacha-avx2-x86_64.S and arch/x86/crypto/chacha-avx512vl-x86_64.S: .rodata.cst32.CTR2BL .rodata.cst32.CTR4BL .rodata.cst32.CTR2BL .rodata.cst32.CTR4BL ...and in arch/x86/crypto/sha256-avx2-asm.S and

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On 4/8/19 4:34 PM, Sedat Dilek wrote: v2: sdi@iniza:~/src/linux-kernel/linux$ git --no-pager diff diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S b/arch/x86/crypto/camellia-aesni-avx-asm_64.S index a14af6eb09cb..712d6a7e8b8f 100644 --- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S +++

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On 4/8/19 4:23 PM, Sedat Dilek wrote: For the .rodata.cst16 part you mean sth. like this? yes, see below --- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S +++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S @@ -573,8 +573,12 @@

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On 4/8/19 3:56 PM, Denys Vlasenko wrote: I propose to change section name, append _module_ name and optionally a comment why this is done:  /* NB: section is mergeable, all elements must be aligned 16-byte blocks */ +/* There is more than one object in this section, let's use module name

Re: CBL issue #431: lld: x86_64: sysfs: cannot create duplicate filename $module/.rodata.cst{16,32}

On 4/8/19 3:36 PM, Sedat Dilek wrote: I fell over your commit "crypto: x86 - make constants readonly, allow linker to merge them" [1] while digging into ClangBuiltLinux issue 431 [0]. I see the following in my dmesg-log: $ grep sysfs: dmesg_5.0.4-rc1-1-amd64-cbl-asmgoto.txt [Fri Mar 22

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

On 3/18/19 7:10 PM, Linus Torvalds wrote: On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra wrote: How about I do a patch that schedules EFLAGS for both 32bit and 64bit, mark this for backporting to infinity. And then at the end, after the objtool-ac bits land, I do a patch removing the EFLAGS

Re: preempt.h: some SOFTIRQ_OFFSET should be SOFTIRQ_MASK?

On Wed, Feb 13, 2019 at 5:05 AM Frederic Weisbecker wrote: > On Tue, Feb 05, 2019 at 07:34:31PM +0100, Denys Vlasenko wrote: > > SOFTIRQ is a counter. > > Why here: > > > > #define in_serving_softirq()(softirq_count() & SOFTIRQ_OFFSET) > > #define in_

preempt.h: some SOFTIRQ_OFFSET should be SOFTIRQ_MASK?

SOFTIRQ is a counter. Why here: #define in_serving_softirq()(softirq_count() & SOFTIRQ_OFFSET) #define in_task() (!(preempt_count() & \ (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET))) we check only lowest bit?

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

On 11/21/2018 02:32 PM, Jens Axboe wrote: On 11/20/18 11:36 PM, Ingo Molnar wrote: * Jens Axboe wrote: So this is a fun one... While I was doing the aio polled work, I noticed that the submitting process spent a substantial amount of time copying data to/from userspace. For aio, that's iocb

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

On 11/21/2018 02:32 PM, Jens Axboe wrote: On 11/20/18 11:36 PM, Ingo Molnar wrote: * Jens Axboe wrote: So this is a fun one... While I was doing the aio polled work, I noticed that the submitting process spent a substantial amount of time copying data to/from userspace. For aio, that's iocb

Re: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

On 07/03/2018 10:46 AM, David Laight wrote: From: Jan Beulich Sent: 03 July 2018 09:36 ... As said there, omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by

Re: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

On 07/03/2018 10:46 AM, David Laight wrote: From: Jan Beulich Sent: 03 July 2018 09:36 ... As said there, omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by

Re: [PATCH] x86/entry/64/compat: Preserve r8-r11 in int $0x80

On 04/18/2018 06:53 PM, Andy Lutomirski wrote: On Tue, Apr 17, 2018 at 8:00 AM, Denys Vlasenko <dvlas...@redhat.com> wrote: This means that the new behavior is there for some 8 years already. Whoever was impacted by it, probably already switched to the new ABI. Current ABI is &

Re: [PATCH] x86/entry/64/compat: Preserve r8-r11 in int $0x80

On 04/18/2018 06:53 PM, Andy Lutomirski wrote: On Tue, Apr 17, 2018 at 8:00 AM, Denys Vlasenko wrote: This means that the new behavior is there for some 8 years already. Whoever was impacted by it, probably already switched to the new ABI. Current ABI is "weaker", it allows kern

Re: [PATCH] x86/entry/64/compat: Preserve r8-r11 in int $0x80

On 04/17/2018 04:36 PM, Andy Lutomirski wrote: 32-bit user code that uses int $80 doesn't care about r8-r11. There is, however, some 64-bit user code that intentionally uses int $0x80 to invoke 32-bit system calls. From what I've seen, basically all such code assumes that r8-r15 are all

Re: [PATCH] x86/entry/64/compat: Preserve r8-r11 in int $0x80

On 04/17/2018 04:36 PM, Andy Lutomirski wrote: 32-bit user code that uses int $80 doesn't care about r8-r11. There is, however, some 64-bit user code that intentionally uses int $0x80 to invoke 32-bit system calls. From what I've seen, basically all such code assumes that r8-r15 are all

Re: [PATCH 34/34] x86/mm/pti: Add Warning when booting on a PCIE capable CPU

On 03/05/2018 11:26 AM, Joerg Roedel wrote: From: Joerg Roedel Warn the user in case the performance can be significantly improved by switching to a 64-bit kernel. Suggested-by: Andy Lutomirski Signed-off-by: Joerg Roedel ---

Re: [PATCH 34/34] x86/mm/pti: Add Warning when booting on a PCIE capable CPU

On 03/05/2018 11:26 AM, Joerg Roedel wrote: From: Joerg Roedel Warn the user in case the performance can be significantly improved by switching to a 64-bit kernel. Suggested-by: Andy Lutomirski Signed-off-by: Joerg Roedel --- arch/x86/mm/pti.c | 16 1 file changed, 16

[PATCH v2] net: make getname() functions return length rather than use int* parameter

not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: David S. Miller <da...@davemloft.net> CC: linu

[PATCH v2] net: make getname() functions return length rather than use int* parameter

not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko CC: David S. Miller CC: linux-kernel@vger.kernel.org CC: net...@vger.kernel.or

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

On 02/12/2018 06:47 PM, David Miller wrote: From: Denys Vlasenko <dvlas...@redhat.com> Date: Mon, 12 Feb 2018 15:15:18 +0100 Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero o

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

On 02/12/2018 06:47 PM, David Miller wrote: From: Denys Vlasenko Date: Mon, 12 Feb 2018 15:15:18 +0100 Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero on success. "int *soc

[PATCH] net: make getname() functions return length rather than use int* parameter

not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: David S. Miller <da...@davemloft.net> CC: linu

[PATCH] net: make getname() functions return length rather than use int* parameter

not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko CC: David S. Miller CC: linux-kernel@vger.kernel.org CC: net...@vger.kernel.or

Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro

On 02/12/2018 02:36 PM, David Laight wrote: From: Denys Vlasenko Sent: 12 February 2018 13:29 ... x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro Those instances where ALLOC_PT_GPREGS_ON_STACK is called just before SAVE_AND_CLEAR_REGS can trivially be replaced by PUSH_AND_CLEAN_REGS

Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro

On 02/12/2018 02:36 PM, David Laight wrote: From: Denys Vlasenko Sent: 12 February 2018 13:29 ... x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro Those instances where ALLOC_PT_GPREGS_ON_STACK is called just before SAVE_AND_CLEAR_REGS can trivially be replaced by PUSH_AND_CLEAN_REGS

Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro

@alien8.de> Cc: Brian Gerst <brge...@gmail.com> Cc: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: dan.j.wil

Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro

be faster, at least on newer CPUs. Suggested-by: Linus Torvalds Signed-off-by: Dominik Brodowski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dan.j.willi...@intel.com Link: http

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 08:02 PM, Joerg Roedel wrote: On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 08:02 PM, Joerg Roedel wrote: On Fri, Feb 09, 2018 at 09:05:02AM -0800, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe not noticeable

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 06:05 PM, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe not noticeable on modern CPU's, but the whole 32-bit code is

Re: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

On 02/09/2018 06:05 PM, Linus Torvalds wrote: On Fri, Feb 9, 2018 at 1:25 AM, Joerg Roedel wrote: + + /* Copy over the stack-frame */ + cld + rep movsb Ugh. This is going to be horrendous. Maybe not noticeable on modern CPU's, but the whole 32-bit code is kind of pointless

Re: [PATCH v2 09/18] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Wed, Nov 22, 2017 at 5:44 AM, Andy Lutomirski wrote: > I want SYSENTER_stack to have reliable overflow detection, which > means that it needs to be at the bottom of a page, not the top. > Move it to the beginning of struct tss_struct and page-align it. > > Also add an

Re: [PATCH v2 09/18] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Wed, Nov 22, 2017 at 5:44 AM, Andy Lutomirski wrote: > I want SYSENTER_stack to have reliable overflow detection, which > means that it needs to be at the bottom of a page, not the top. > Move it to the beginning of struct tss_struct and page-align it. > > Also add an assertion to make sure

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 06:14 PM, Paolo Bonzini wrote: On 08/11/2017 18:09, Denys Vlasenko wrote: On 11/08/2017 05:57 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:53 AM, Denys Vlasenko <dvlas...@redhat.com> wrote: We can postpone enabling UMIP by default by a year or so. By this time, ne

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 06:14 PM, Paolo Bonzini wrote: On 08/11/2017 18:09, Denys Vlasenko wrote: On 11/08/2017 05:57 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:53 AM, Denys Vlasenko wrote: We can postpone enabling UMIP by default by a year or so. By this time, new Wine will be on majority

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 05:57 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:53 AM, Denys Vlasenko <dvlas...@redhat.com> wrote: We can postpone enabling UMIP by default by a year or so. By this time, new Wine will be on majority of users' machines. So you are suggesting we run unneces

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 05:57 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:53 AM, Denys Vlasenko wrote: We can postpone enabling UMIP by default by a year or so. By this time, new Wine will be on majority of users' machines. So you are suggesting we run unnecessarily insecure, only in order

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 05:34 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:14 AM, Denys Vlasenko <dvlas...@redhat.com> wrote: Can we avoid maintain emulation of these isns, by asking Wine to remove their use instead? If we ask the Wine people to remove the instruction use, that may mean t

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 05:34 PM, Linus Torvalds wrote: On Wed, Nov 8, 2017 at 8:14 AM, Denys Vlasenko wrote: Can we avoid maintain emulation of these isns, by asking Wine to remove their use instead? If we ask the Wine people to remove the instruction use, that may mean that we can avoid

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 12:00 PM, tip-bot for Ricardo Neri wrote: Commit-ID: 1e5db223696afa55e6a038fac638f759e1fdcc01 Gitweb: https://git.kernel.org/tip/1e5db223696afa55e6a038fac638f759e1fdcc01 Author: Ricardo Neri AuthorDate: Sun, 5 Nov 2017 18:27:52 -0800

Re: [tip:x86/asm] x86/umip: Add emulation code for UMIP instructions

On 11/08/2017 12:00 PM, tip-bot for Ricardo Neri wrote: Commit-ID: 1e5db223696afa55e6a038fac638f759e1fdcc01 Gitweb: https://git.kernel.org/tip/1e5db223696afa55e6a038fac638f759e1fdcc01 Author: Ricardo Neri AuthorDate: Sun, 5 Nov 2017 18:27:52 -0800 Committer: Ingo Molnar CommitDate:

Is GET_CR0_INTO_EAX macro unused?

Hi Andy, From by git archaeology, looks like last use of GET_CR0_INTO_EAX was removed long ago, in 2008 (see commit below). Right now, I only grep it here in a comment in entry_32.S: /* * We use macros for low-level operations which need to be overridden * for paravirtualization. The

Is GET_CR0_INTO_EAX macro unused?

Hi Andy, From by git archaeology, looks like last use of GET_CR0_INTO_EAX was removed long ago, in 2008 (see commit below). Right now, I only grep it here in a comment in entry_32.S: /* * We use macros for low-level operations which need to be overridden * for paravirtualization. The

Re: [PATCH] KVM: SVM: refactor avic VM ID allocation

On 08/17/2017 04:33 PM, Paolo Bonzini wrote: On 15/08/2017 22:12, Radim Krčmář wrote: 2017-08-11 22:11+0200, Denys Vlasenko: With lightly tweaked defconfig: textdata bss dec hex filename 11259661 5109408 2981888 19350957 12745ad vmlinux.before 11259661 5109408 884736

Re: [PATCH] KVM: SVM: refactor avic VM ID allocation

On 08/17/2017 04:33 PM, Paolo Bonzini wrote: On 15/08/2017 22:12, Radim Krčmář wrote: 2017-08-11 22:11+0200, Denys Vlasenko: With lightly tweaked defconfig: textdata bss dec hex filename 11259661 5109408 2981888 19350957 12745ad vmlinux.before 11259661 5109408 884736

[PATCH] lib/raid6: align AVX512 constants to 512 bits, not bytes

Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: mi...@redhat.com Cc: Jim Kukunas <james.t.kuku...@linux.intel.com> Cc: Fenghua Yu <fenghua...@intel.com> Cc: Megha Dey <megha@linux.intel.com> Cc: Gayatri Kammela <gayat

[PATCH] lib/raid6: align AVX512 constants to 512 bits, not bytes

Signed-off-by: Denys Vlasenko Cc: H. Peter Anvin Cc: mi...@redhat.com Cc: Jim Kukunas Cc: Fenghua Yu Cc: Megha Dey Cc: Gayatri Kammela Cc: Shaohua Li Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org --- avx512.o before: Sections: Idx Name Size VMA

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On Thu, Aug 10, 2017 at 12:00 PM, Lan Tianyu wrote: > Intel Xeon phi chip will support 352 logical threads. For HPC usage > case, it will create a huge VM with vcpu number as same as host cpus. This > patch is to increase max vcpu number to 352. This number was bumped in

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On Thu, Aug 10, 2017 at 12:00 PM, Lan Tianyu wrote: > Intel Xeon phi chip will support 352 logical threads. For HPC usage > case, it will create a huge VM with vcpu number as same as host cpus. This > patch is to increase max vcpu number to 352. This number was bumped in the past to 288 to

[PATCH] KVM: SVM: delete avic_vm_id_bitmap (2 megabyte static array)

With lightly tweaked defconfig: textdata bss dec hex filename 11259661 5109408 2981888 19350957 12745ad vmlinux.before 11259661 5109408 884736 17253805 10745ad vmlinux.after Only compile-tested. Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> Cc: Joerg Roe

[PATCH] KVM: SVM: delete avic_vm_id_bitmap (2 megabyte static array)

With lightly tweaked defconfig: textdata bss dec hex filename 11259661 5109408 2981888 19350957 12745ad vmlinux.before 11259661 5109408 884736 17253805 10745ad vmlinux.after Only compile-tested. Signed-off-by: Denys Vlasenko Cc: Joerg Roedel Cc: pbonz...@redhat.com Cc

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

On Tue, Jun 27, 2017 at 12:28 PM, Masami Hiramatsu wrote: > Use md5sum so that it takes less time of checking > trace logs update. Since busybox tail/cat takes too > long time to read the trace log, this uses md5sum > to check whether trace log is updated or not. > >

Re: [PATCH] selftests: ftrace: Use md5sum to take less time of checking logs

On Tue, Jun 27, 2017 at 12:28 PM, Masami Hiramatsu wrote: > Use md5sum so that it takes less time of checking > trace logs update. Since busybox tail/cat takes too > long time to read the trace log, this uses md5sum > to check whether trace log is updated or not. > > Signed-off-by: Masami

Re: [PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

On 06/21/2017 09:24 PM, Marcelo Ricardo Leitner wrote: On Wed, Jun 21, 2017 at 07:03:27PM +0200, Denys Vlasenko wrote: This function compiles to 147 bytes of machine code. 13 callsites. I'm no expert on SCTP events, but quick reading of SCTP docs tells me that SCTP events are not happening

Re: [PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

On 06/21/2017 09:24 PM, Marcelo Ricardo Leitner wrote: On Wed, Jun 21, 2017 at 07:03:27PM +0200, Denys Vlasenko wrote: This function compiles to 147 bytes of machine code. 13 callsites. I'm no expert on SCTP events, but quick reading of SCTP docs tells me that SCTP events are not happening

Can avic_vm_id_bitmap be made smaller? 2 mbytes feels too large

#define AVIC_VM_ID_BITS24 #define AVIC_VM_ID_NR (1 << AVIC_VM_ID_BITS) ... static DECLARE_BITMAP(avic_vm_id_bitmap, AVIC_VM_ID_NR); The above results in a data object which is 2 megabytes large. avic_vm_init() -> avic_get_next_vm_id() allocates a new

Can avic_vm_id_bitmap be made smaller? 2 mbytes feels too large

#define AVIC_VM_ID_BITS24 #define AVIC_VM_ID_NR (1 << AVIC_VM_ID_BITS) ... static DECLARE_BITMAP(avic_vm_id_bitmap, AVIC_VM_ID_NR); The above results in a data object which is 2 megabytes large. avic_vm_init() -> avic_get_next_vm_id() allocates a new

[PATCH] minix: Deinline get_block, save 2691 bytes

This function compiles to 1402 bytes of machine code. It has 2 callsites, and also a not-inlined copy gets created by compiler anyway since its address gets passed as a parameter to block_truncate_page(). Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Al Viro <v...@zeniv.lin

[PATCH] minix: Deinline get_block, save 2691 bytes

This function compiles to 1402 bytes of machine code. It has 2 callsites, and also a not-inlined copy gets created by compiler anyway since its address gets passed as a parameter to block_truncate_page(). Signed-off-by: Denys Vlasenko CC: Al Viro CC: linux-fsde...@vger.kernel.org CC: linux

[PATCH] kernel/sched/fair.c: Deinline update_load_avg, save 8720 bytes

This function compiles to 1378 bytes of machine code. 8 callsites. Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Peter Zijlstra <pet...@infradead.org> CC: linux-kernel@vger.kernel.org --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

[PATCH] kernel/sched/fair.c: Deinline update_load_avg, save 8720 bytes

This function compiles to 1378 bytes of machine code. 8 callsites. Signed-off-by: Denys Vlasenko CC: Peter Zijlstra CC: linux-kernel@vger.kernel.org --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index

[PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Vlad Yasevich <vyasev...@gmail.com> CC: Neil Horman <nhor...@tuxdriver.com> CC: David Miller <da...@davemloft.net> CC: linux-s...@vger.kernel.org CC: net...@vger.kernel.org CC: linux-kernel@vger.kernel.org --- Changed since v

[PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

-off-by: Denys Vlasenko CC: Vlad Yasevich CC: Neil Horman CC: David Miller CC: linux-s...@vger.kernel.org CC: net...@vger.kernel.org CC: linux-kernel@vger.kernel.org --- Changed since v1: * reindented function argument list net/sctp/ulpevent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Vlad Yasevich <vyasev...@gmail.com> CC: Neil Horman <nhor...@tuxdriver.com> CC: David Miller <da...@davemloft.net> CC: linux-s...@vger.kernel.org CC: net...@vger.kernel.org CC: linux-kernel@vger.kernel.org --- net/sctp/u

[PATCH] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

-off-by: Denys Vlasenko CC: Vlad Yasevich CC: Neil Horman CC: David Miller CC: linux-s...@vger.kernel.org CC: net...@vger.kernel.org CC: linux-kernel@vger.kernel.org --- net/sctp/ulpevent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sctp/ulpevent.c b/net/sctp

[PATCH] liquidio: stop using huge static buffer, save 4096k in .data

Only compile-tested - I don't have the hardware. >From code inspection, octeon_pci_write_core_mem() appears to be safe wrt unaligned source. In any case, u8 fbuf[] was not guaranteed to be aligned anyway. Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Felix Manlunas <

[PATCH] liquidio: stop using huge static buffer, save 4096k in .data

Only compile-tested - I don't have the hardware. >From code inspection, octeon_pci_write_core_mem() appears to be safe wrt unaligned source. In any case, u8 fbuf[] was not guaranteed to be aligned anyway. Signed-off-by: Denys Vlasenko CC: Felix Manlunas CC: Prasad Kanneganti CC: De

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:23 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:23 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the

[PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

FG) - all bits are "reserved" MSRC001_102A Bus Unit Configuration 2 (BU_CFG2) 16h_Mod_30h-3Fh_BKDG: FP_CFG now has one documented field CC: Ingo Molnar <mi...@redhat.com> CC: Andy Lutomirski <l...@kernel.org> CC: Borislav Petkov <b...@alien8.de> CC: Brian Gerst <

[PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

tion (FP_CFG) - all bits are "reserved" MSRC001_102A Bus Unit Configuration 2 (BU_CFG2) 16h_Mod_30h-3Fh_BKDG: FP_CFG now has one documented field CC: Ingo Molnar CC: Andy Lutomirski CC: Borislav Petkov CC: Brian Gerst CC: Peter Zijlstra CC: "H. Peter Anvin" CC: x...@kernel.o

Re: [PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

On 04/25/2017 02:59 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 02:16:55PM +0200, Denys Vlasenko wrote: However, all IBS registers are in this range. I knew you were gonna say that. But IBS registers are architectural too in the sense that they are behind a CPUID bit. DRi_ADDR_MASK

Re: [PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

On 04/25/2017 02:59 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 02:16:55PM +0200, Denys Vlasenko wrote: However, all IBS registers are in this range. I knew you were gonna say that. But IBS registers are architectural too in the sense that they are behind a CPUID bit. DRi_ADDR_MASK

Re: [PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

On 04/25/2017 01:59 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 01:45:41PM +0200, Denys Vlasenko wrote: Before this patch, we have a define for MSR 0xc0011021: MSR_F15H_IC_CFG. But it exists starting from K8, so it's not really a Fam15h MSR only. Lat's call it MSR_AMD64_IC_CFG. Except

Re: [PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

On 04/25/2017 01:59 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 01:45:41PM +0200, Denys Vlasenko wrote: Before this patch, we have a define for MSR 0xc0011021: MSR_F15H_IC_CFG. But it exists starting from K8, so it's not really a Fam15h MSR only. Lat's call it MSR_AMD64_IC_CFG. Except

[PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

C_CFG) MSRC001_1023 Bus Unit Configuration (BU_CFG) MSRC001_1028 Floating Point Configuration (FP_CFG) - all bits are "reserved" MSRC001_102A Bus Unit Configuration 2 (BU_CFG2) 16h_Mod_30h-3Fh_BKDG: FP_CFG now has one documented field CC: Ingo Molnar <mi...@redhat.com> CC: Andy Lutomirski

[PATCH] x86, msr: Better document AMD "tweak MSRs", rename MSR_F15H_IC_CFG

MSRC001_1023 Bus Unit Configuration (BU_CFG) MSRC001_1028 Floating Point Configuration (FP_CFG) - all bits are "reserved" MSRC001_102A Bus Unit Configuration 2 (BU_CFG2) 16h_Mod_30h-3Fh_BKDG: FP_CFG now has one documented field CC: Ingo Molnar CC: Andy Lutomirski CC: Borislav Petkov

Re: [tip:x86/mm] x86/asm: Remove __VIRTUAL_MASK_SHIFT==47 assert

On 04/05/2017 01:12 PM, Kirill A. Shutemov wrote: On Tue, Apr 04, 2017 at 05:36:33PM +0200, Denys Vlasenko wrote: diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 044d18e..f07b4ef 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -265,12 +265,9

Re: [tip:x86/mm] x86/asm: Remove __VIRTUAL_MASK_SHIFT==47 assert

On 04/05/2017 01:12 PM, Kirill A. Shutemov wrote: On Tue, Apr 04, 2017 at 05:36:33PM +0200, Denys Vlasenko wrote: diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 044d18e..f07b4ef 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -265,12 +265,9

Re: [tip:x86/mm] x86/asm: Remove __VIRTUAL_MASK_SHIFT==47 assert

alien8.de> Cc: Brian Gerst <brge...@gmail.com> Cc: Dave Hansen <dave.han...@intel.com> Cc: Denys Vlasenko <dvlas...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc:

Re: [tip:x86/mm] x86/asm: Remove __VIRTUAL_MASK_SHIFT==47 assert

by: Kirill A. Shutemov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-a...@vger.kernel.org

Re: random: /dev/random often returns short reads

On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o <ty...@mit.edu> wrote: > On Wed, Jan 18, 2017 at 04:44:54PM +0100, Denys Vlasenko wrote: >> In this case, what code does is it returns fewer bytes, >> even though *it has enough random bytes to return the full request*. >&

Re: random: /dev/random often returns short reads

On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o wrote: > On Wed, Jan 18, 2017 at 04:44:54PM +0100, Denys Vlasenko wrote: >> In this case, what code does is it returns fewer bytes, >> even though *it has enough random bytes to return the full request*. >> >> This happ

Re: [PATCH] x86/crypto: make constants readonly, allow linker to merge them

On 01/20/2017 12:09 AM, Thomas Gleixner wrote: On Thu, 19 Jan 2017, Denys Vlasenko wrote: A lot of asm-optimized routines in arch/x86/crypto/ keep its constants in .data. This is wrong, they should be on .rodata. Mnay of these constants are the same in different modules. For example, 128-bit

Re: [PATCH] x86/crypto: make constants readonly, allow linker to merge them

On 01/20/2017 12:09 AM, Thomas Gleixner wrote: On Thu, 19 Jan 2017, Denys Vlasenko wrote: A lot of asm-optimized routines in arch/x86/crypto/ keep its constants in .data. This is wrong, they should be on .rodata. Mnay of these constants are the same in different modules. For example, 128-bit

Re: random: /dev/random often returns short reads

On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o wrote: > In the ideal world, yes. I've acknowledged this is a bug, in the "be > conservative in what you send, liberal in what you receive" sense.. > But no one complained for three year, and userspace needs to be able > to retry

Re: random: /dev/random often returns short reads

On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o wrote: > In the ideal world, yes. I've acknowledged this is a bug, in the "be > conservative in what you send, liberal in what you receive" sense.. > But no one complained for three year, and userspace needs to be able > to retry short reads instead

[PATCH] x86/crypto: make constants readonly, allow linker to merge them

link stage will use garbage collection to eliminate unused sections (ld --gc-sections). Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Herbert Xu <herb...@gondor.apana.org.au> CC: Josh Poimboeuf <jpoim...@redhat.com> CC: Xiaodong Liu <xiaodong@intel.com> CC: Megh

[PATCH] x86/crypto: make constants readonly, allow linker to merge them

link stage will use garbage collection to eliminate unused sections (ld --gc-sections). Signed-off-by: Denys Vlasenko CC: Herbert Xu CC: Josh Poimboeuf CC: Xiaodong Liu CC: Megha Dey CC: linux-cry...@vger.kernel.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org -

[PATCH] x86/crypto: fix %progbits -> @progbits

%progbits form is used on ARM (where @ is a comment char). x86 consistently uses @progbits everywhere else. Signed-off-by: Denys Vlasenko <dvlas...@redhat.com> CC: Herbert Xu <herb...@gondor.apana.org.au> CC: Josh Poimboeuf <jpoim...@redhat.com> CC: Xiaodong Liu <xiaod

[PATCH] x86/crypto: fix %progbits -> @progbits

%progbits form is used on ARM (where @ is a comment char). x86 consistently uses @progbits everywhere else. Signed-off-by: Denys Vlasenko CC: Herbert Xu CC: Josh Poimboeuf CC: Xiaodong Liu CC: Megha Dey CC: George Spelvin CC: linux-cry...@vger.kernel.org CC: x...@kernel.org CC: linux

Re: random: /dev/random often returns short reads

On 01/17/2017 11:29 PM, H. Peter Anvin wrote: On 01/17/17 09:34, Denys Vlasenko wrote: On 01/17/2017 06:15 PM, Theodore Ts'o wrote: On Tue, Jan 17, 2017 at 09:21:31AM +0100, Denys Vlasenko wrote: If someone wants to send me a patch, I'll happily take a look at it, Will something along

Re: random: /dev/random often returns short reads

On 01/17/2017 11:29 PM, H. Peter Anvin wrote: On 01/17/17 09:34, Denys Vlasenko wrote: On 01/17/2017 06:15 PM, Theodore Ts'o wrote: On Tue, Jan 17, 2017 at 09:21:31AM +0100, Denys Vlasenko wrote: If someone wants to send me a patch, I'll happily take a look at it, Will something along

Re: random: /dev/random often returns short reads

On 01/17/2017 06:15 PM, Theodore Ts'o wrote: On Tue, Jan 17, 2017 at 09:21:31AM +0100, Denys Vlasenko wrote: If someone wants to send me a patch, I'll happily take a look at it, Will something along these lines be accepted? The problem is that this won't work. In the cases that we're

Re: random: /dev/random often returns short reads

On 01/17/2017 06:15 PM, Theodore Ts'o wrote: On Tue, Jan 17, 2017 at 09:21:31AM +0100, Denys Vlasenko wrote: If someone wants to send me a patch, I'll happily take a look at it, Will something along these lines be accepted? The problem is that this won't work. In the cases that we're

Re: random: /dev/random often returns short reads

On Tue, Jan 17, 2017 at 5:36 AM, Theodore Ts'o <ty...@mit.edu> wrote: > On Mon, Jan 16, 2017 at 07:50:55PM +0100, Denys Vlasenko wrote: >> >> /dev/random can legitimately returns short reads >> when there is not enough entropy for the full request. > > Yes,

  1   2   3   4   5   6   7   8   9   10   >