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/
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
arch/x86/crypto/sha512-avx2-asm.S:
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
+++ b
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 @@
ENDPROC(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_a
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
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 10:32:09
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
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_
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?
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 an
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&T 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 u
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
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 preserv
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 ins
Userspace API is 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.
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 *sockle
Userspace API is 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.
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
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
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 on
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 o
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 tha
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 of
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 ord
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 the
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: We
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 followin
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
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
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 accomm
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
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 Hiramats
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 happeni
#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 vm_i
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
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
igned-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 del
igned-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
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
C
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.
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 realiza
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
CC: Brian Gerst
CC: Peter Zijlstra
CC: "H. Peter Anvin"
CC: x..
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
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
ation (DC_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: B
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
ff-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.kerne
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
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
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
meday 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.
%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
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 somet
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 c
On Tue, Jan 17, 2017 at 5:36 AM, Theodore Ts'o 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, but callers of /dev
> # while ./eat_dev_random; do ./eat_dev_random; done; ./eat_dev_random
> read of 32 returns 32
> read of 32 returns 32
> read of 32 returns 28
> read of 32 returns 24
>
> Just two few first requests worked, and then ouch...
>
> I think this is what happens here:
> we transfer 4 bytes of entrophy t
Hi,
/dev/random can legitimately returns short reads
when there is not enough entropy for the full request.
However, now it does so far too often,
and it appears to be a bug:
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int fd, ret, len;
in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Denys Vlasenko
Acked-by: Kees Cook
Acked-by: Michael Ellerman
Tested-by: Jason Gunthorpe
CC: Andrew Morton
CC: Benjamin Herrenschmidt
C
posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Denys Vlasenko
Acked-by: Kees Cook
Acked-by: Michael Ellerman
Tested-by: Jason Gunthorpe
CC: Andrew Morton
CC: Benjamin Herrenschmidt
use all callers use values far from "pathological" ones,
such as 500 and 1000 - these work fine with buggy code.
This was reported in 2006 but was missed.
Signed-off-by: Denys Vlasenko
CC: James Bottomley
CC: Hannes Reinicke
CC: linux-s...@vger.kernel.org
CC: linux-kernel@vg
On 10/13/2016 02:46 PM, Josh Poimboeuf wrote:
On Tue, Oct 11, 2016 at 10:38:42PM +0200, Arnd Bergmann wrote:
On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote:
Notice how it just falls off the end of the function. We had a similar
bug before:
https://lkml.kernel.org/r/20160
On Fri, Sep 9, 2016 at 2:21 PM, Chen Yu wrote:
> On some platforms, there is occasional panic triggered when trying to
> resume from hibernation, a typical panic looks like:
>
> "BUG: unable to handle kernel paging request at 880085894000
> IP: [] load_image_lzo+0x8c2/0xe70"
>
> Investigation
posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Denys Vlasenko
Acked-by: Kees Cook
Acked-by: Michael Ellerman
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: "Aneesh Kumar K.V
Hello,
I would like to discuss this commit:
commit d3d7e6c65f75de18ced10a98595a847f9f95f0ce
Author: Raghu Vatsavayi
Date: Tue Jun 21 22:53:07 2016 -0700
liquidio: Firmware image download
This patch has firmware image related changes for: firmware
release upon failure, support lat
Commit-ID: 1827822902cf659d60d3413fd42c7e6cbd18df4d
Gitweb: http://git.kernel.org/tip/1827822902cf659d60d3413fd42c7e6cbd18df4d
Author: Denys Vlasenko
AuthorDate: Sun, 18 Sep 2016 20:21:25 +0200
Committer: Ingo Molnar
CommitDate: Wed, 21 Sep 2016 15:02:12 +0200
x86/e820: Use much less
Commit-ID: 475339684ef19e46f4702e2d185a869a5c454688
Gitweb: http://git.kernel.org/tip/475339684ef19e46f4702e2d185a869a5c454688
Author: Denys Vlasenko
AuthorDate: Sat, 17 Sep 2016 23:39:26 +0200
Committer: Ingo Molnar
CommitDate: Wed, 21 Sep 2016 15:02:12 +0200
x86/e820: Prepare e280
Commit-ID: 8c2103f224216a45c1a4d7aebbc13f3e007cde34
Gitweb: http://git.kernel.org/tip/8c2103f224216a45c1a4d7aebbc13f3e007cde34
Author: Denys Vlasenko
AuthorDate: Sat, 17 Sep 2016 23:39:25 +0200
Committer: Ingo Molnar
CommitDate: Wed, 21 Sep 2016 15:02:11 +0200
x86/e820: Mark some
Commit-ID: cff9ab2b291e64259d97add48fe073c081afe4e2
Gitweb: http://git.kernel.org/tip/cff9ab2b291e64259d97add48fe073c081afe4e2
Author: Denys Vlasenko
AuthorDate: Tue, 13 Sep 2016 20:12:32 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Sep 2016 00:31:19 +0200
x86/apic: Get rid of
are freed
in free_initmem(), allocate smaller blocks, copy maps there,
and change pointers.
The late switch makes sure that all functions which can be used to change
e820 maps are no longer accessible (they are all __init functions).
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC
On 09/18/2016 10:31 AM, Ingo Molnar wrote:
* Denys Vlasenko wrote:
On 09/15/2016 09:04 AM, Ingo Molnar wrote:
* Denys Vlasenko wrote:
The maximum size of e820 map array for EFI systems is defined as
E820_X_MAX (E820MAX + 3 * MAX_NUMNODES).
In x86_64 defconfig, this ends up with E820_X_MAX
are freed
in free_initmem(), allocate smaller blocks, copy maps there,
and change pointers.
The late switch makes sure that all functions which can be used to change
e820 maps are no longer accessible (they are all __init functions).
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC
They are all called only from other __init functions in e820.c
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/kernel/e820.c | 12 +
This patch turns e820 and e820_saved into pointers to e820 tables,
of the same size as before.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off
On 09/15/2016 09:04 AM, Ingo Molnar wrote:
* Denys Vlasenko wrote:
The maximum size of e820 map array for EFI systems is defined as
E820_X_MAX (E820MAX + 3 * MAX_NUMNODES).
In x86_64 defconfig, this ends up with E820_X_MAX = 320, e820 and e820_saved
are 6404 bytes each.
With larger configs
riable, u8 boot_cpu_apic_version.
(Why u8?
APIC version values as of year 2016 are no larger than 0x1f on all known CPUs.
Version field in the APIC register is 8 bit wide - not likely
to overflow byte range in foreseeable future.)
"APIC version mismatch" check is not removed.
Signed-off-by
On 09/13/2016 05:33 PM, Thomas Gleixner wrote:
On Sun, 11 Sep 2016, Borislav Petkov wrote:
On Fri, Sep 09, 2016 at 10:32:04AM +0200, Denys Vlasenko wrote:
This array is [MAX_LOCAL_APIC], and MAX_LOCAL_APIC can easily be up to 32k.
This patch changes apic_version[] array elements from int to
ange value
into this argument.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/mpspec.h | 4 ++--
arch/x86/kernel/acpi/boot.c | 2
maps,
allocate smaller alloc_bootmem blocks, copy maps there, and change pointers.
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
Change
maps,
allocate smaller alloc_bootmem blocks, copy maps there, and change pointers.
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x
They are all called only from other __init functions.
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Andy Lutomirski
CC: "H. Peter Anvin"
CC: Borislav Petkov
CC: Brian Gerst
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/kernel/e820.c | 12 ++--
1 fi
On 08/19/2016 12:54 PM, Paolo Bonzini wrote:
On 18/08/2016 19:24, Linus Torvalds wrote:
I didn't do CPL0 tests yet. Realized that cli/sti can be tested in userspace
if we set iopl(3) first.
Yes, but it might not be the same. So the timings could be very
different from a cpl0 case.
FWIW I rece
posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Denys Vlasenko
Reviewed-by: Kees Cook
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: "Aneesh Kumar K.V"
CC: Kees Cook
On 08/21/2016 05:47 PM, Aneesh Kumar K.V wrote:
Denys Vlasenko writes:
On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt,
or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 14 00 WA 0 0 4
[18
On 08/10/2016 03:00 PM, Denys Vlasenko wrote:
On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt,
or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 14 00 WA 0 0 4
[18] .plt NOBITS
On 08/18/2016 07:24 PM, Linus Torvalds wrote:
That said, your numbers really aren't very convincing. If popf really
is just 10 cycles on modern Intel hardware, it's already fast enough
that I really don't think it matters.
It's 20 cycles. I was wrong in my email, I forgot that the insn count
al
On 08/18/2016 07:47 PM, Denys Vlasenko wrote:
On 08/18/2016 07:24 PM, Linus Torvalds wrote:
That said, your numbers really aren't very convincing. If popf really
is just 10 cycles on modern Intel hardware, it's already fast enough
that I really don't think it matters.
It
Of course, somebody really should do timings on modern CPU's (in cpl0,
comparing native_fl() that enables interrupts with a popf)
I didn't do CPL0 tests yet. Realized that cli/sti can be tested in userspace
if we set iopl(3) first.
Surprisingly, STI is slower than CLI. A loop with 27 CLI's and
On 08/18/2016 11:21 AM, Denys Vlasenko wrote:
Of course, if somebody uses native_restore_fl() to actually *disable*
interrupts (when they weren't already disabled), then this untested
patch will just not work. But why would you do somethign so stupid?
Famous last words...
Looking around
On 08/17/2016 11:35 PM, Linus Torvalds wrote:
On Wed, Aug 17, 2016 at 2:26 PM, Linus Torvalds
wrote:
Of course, if somebody uses native_restore_fl() to actually *disable*
interrupts (when they weren't already disabled), then this untested
patch will just not work. But why would you do somethig
On 08/17/2016 09:32 PM, Linus Torvalds wrote:
On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko wrote:
Exactly. And more:
All of which is ENTIRELY IRRELEVANT.
The 2-page pseudo-code is about behavior. It's trivial to
short-circuit. There are obvious optimizations, which involve
On 08/17/2016 09:13 PM, Andy Lutomirski wrote:
On Wed, Aug 17, 2016 at 12:01 PM, Linus Torvalds
wrote:
On Aug 17, 2016 11:41 AM, "Denys Vlasenko" wrote:
OTOH 5 years will inevitably pass.
Yes. But in five years, maybe we'll have a popf that is faster anyway.
I'd act
On 08/17/2016 07:32 PM, Linus Torvalds wrote:
On Wed, Aug 17, 2016 at 10:20 AM, Denys Vlasenko wrote:
Last year, a proposal was floated to avoid costly POPF.
In particular, each spin_unlock_irqrestore() does it,
a rather common operation.
Quiet frankly, it takes so long for hw features
On 08/17/2016 07:30 PM, Christian König wrote:
But in my measurements POPF is not fast even in the case where restored
flags are not changed at all:
mov $200*1000*1000, %eax
pushf
pop %rbx
.balign 64
loop: push
Last year, a proposal was floated to avoid costly POPF.
In particular, each spin_unlock_irqrestore() does it,
a rather common operation.
https://lkml.org/lkml/2015/4/21/290
[RFC PATCH] x86/asm/irq: Don't use POPF but STI
* Andy Lutomirski wrote:
> Another different approach would be to
On 08/12/2016 07:39 AM, Srikar Dronamraju wrote:
* Denys Vlasenko [2016-08-11 17:45:21]:
Since instruction decoder now supports EVEX-encoded insns, two fixes are needed
to correctly handle them in uprobes.
Could you please add the commit that helps support the insns in the
Changelog
Commit-ID: 68187872c76a96ed4db7bfb064272591f02e208b
Gitweb: http://git.kernel.org/tip/68187872c76a96ed4db7bfb064272591f02e208b
Author: Denys Vlasenko
AuthorDate: Thu, 11 Aug 2016 17:45:21 +0200
Committer: Ingo Molnar
CommitDate: Fri, 12 Aug 2016 08:29:24 +0200
uprobes/x86: Fix RIP
lates vex_prefix.bytes[2]
for all flavors of (e)vex encodings, even for vex2.
Signed-off-by: Denys Vlasenko
CC: Jim Keniston
CC: Masami Hiramatsu
CC: Srikar Dronamraju
CC: Ingo Molnar
CC: Oleg Nesterov
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/kernel/uprobes.c
On 08/10/2016 06:36 AM, Michael Ellerman wrote:
Denys Vlasenko writes:
On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
or with a toolchain which defaults to it) look like this:
...
arch/powerpc/include/asm/page.h| 10 +-
arch/powerpc/include/asm
On 08/10/2016 12:43 AM, Kees Cook wrote:
-static int do_brk(unsigned long addr, unsigned long len)
+static int do_brk_flags(unsigned long addr, unsigned long len, unsigned long
flags)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma, *prev;
- unsigned long
posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Denys Vlasenko
Reviewed-by: Kees Cook
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Kees Cook
CC: Oleg Nesterov
CC: Michael
1 - 100 of 1280 matches
Mail list logo
