+ free(config_detected);
> > + return ret;
> > +}
>
> it's lot of tricky code because of one file, how about we compile
> tips.txt in perf binary directly? it might be even less code changes
I'm not sure about changes size, but anyway i agree that it makes more
sense to compile tips.txt in perf bi
remapped by using --file-prefix-map option that is available
starting from version 3.7.1.
Signed-off-by: Denys Zagorui
---
tools/perf/Build | 1 -
tools/perf/Makefile.config| 9 +
tools/perf/builtin-report.c | 13 +++-
tools/perf/tests/Build| 2 +-
tools/perf
get_exec_abs_path();
> > + if (exec_path == NULL)
> > + return -1;
> > +
> > + if (asprintf(&pythonpath, "%spython", exec_path) < 0)
>
> are we sure there's always trailing '/' in exec_path ?
Yes, it should be. /proc/se
determined in runtime.
bison stores full paths in generated files. This can be
remapped by using --file-prefix-map option that is available
starting from version 3.7.1.
Signed-off-by: Denys Zagorui
---
tools/lib/subcmd/exec-cmd.c | 21 +
tools/lib/subcmd/exec-cmd.h | 1
____
From: Jiri Olsa
Sent: 15 March 2021 14:28
To: Denys Zagorui -X (dzagorui - GLOBALLOGIC INC at Cisco)
Cc: pet...@infradead.org; mi...@redhat.com; a...@kernel.org;
mark.rutl...@arm.com; alexander.shish...@linux.intel.com; namhy...@kernel.org;
linux-kernel@vger.kernel.org
determined in runtime.
bison stores full paths in generated files. This can be
remapped by using --file-prefix-map option that is available
starting from version 3.6.3.
Signed-off-by: Denys Zagorui
---
tools/lib/subcmd/exec-cmd.c | 21 +
tools/lib/subcmd/exec-cmd.h | 1
t;).
ok, i see
> > Assembler sources also use __FILE__
> > macro so this flag should be also apllied to that sources.
>
> I fixed "apllied" to "applied".
thanks, sorry for this typo
> Maybe, "that sources" should be "those sources".
yes
Thanks,
Denys
> ping
Any comments on this ?
Thanks,
Denys
> Follow-up to a73619a845d5 ("kbuild: use -fmacro-prefix-map to make
> __FILE__ a relative path") commit. Assembler sources also use __FILE__
> macro so this flag should be also apllied to that sources.
>
> Signed-off-by: Denys Zagorui
> ---
> Makefile | 2 +-
>
Follow-up to a73619a845d5 ("kbuild: use -fmacro-prefix-map to make
__FILE__ a relative path") commit. Assembler sources also use __FILE__
macro so this flag should be also apllied to that sources.
Signed-off-by: Denys Zagorui
---
Makefile | 2 +-
1 file changed, 1 insertion(+),
Follow-up to a73619a845d5 ("kbuild: use -fmacro-prefix-map to make
__FILE__ a relative path") commit. Assembler sources also use __FILE__
macro so this flag should be also apllied to that sources.
Signed-off-by: Denys Zagorui
---
Makefile | 2 +-
1 file changed, 1 insertion(+),
Follow-up to a73619a845d5 ("kbuild: use -fmacro-prefix-map to make
__FILE__ a relative path") commit. Assembler sources also use __FILE__
macro so this flag should be also apllied to that sources.
Signed-off-by: Denys Zagorui
---
Makefile | 1 +
1 file changed, 1 insertion(+)
di
>This doesn't seem appropriate at all. If anything UC addresses
>should be blocked and the Intel driver change reverted. We have
>a well defined way to add secondary UC addresses and the MC interfaces
>are not it.
As I understand by ‘well defined way’ you mean macvlan feature. But macvlan
is mo
s API.
(2f41f3358672 i40e/i40evf: fix unicast mac address add)
This patch adds check whether passed mac addr is uc or mc and adds
this mac addr to the corresponding list. Add 'global' variant for
adding/removing uc addresses similarly to mc.
Signed-off-by: Denys Zagorui
---
include/linux/netd
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/
s API.
(2f41f3358672 i40e/i40evf: fix unicast mac address add)
This patch adds check whether passed mac addr is uc or mc and adds
this mac addr to the corresponding list. Add 'global' variant for
adding/removing uc addresses similarly to mc.
Signed-off-by: Denys Zagorui
---
include/linux/netd
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?
Fathi Boudra
> >>>
> >>>Relax CC assignment to allow to override CC in the top-level Makefile.
> >>>
> >>>Signed-off-by: Denys Dmytriyenko
^^^ I am the original author of the patch and this is my signed-off line.
> Author signed-off missing on this
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
t;too much work" messages
First one doesn't help now, last one was reverted
(12de375ec493ab1767d4a07dde823e63ae5edc21) in fact
it doesn't fix anything. So procesing interrupts in
kthread give us an opportunity to perform rescheduling
periodically.
Cc: Jiri Slaby
Signed-off-by: Denys Zagoru
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
t;too much work" messages
First one doesn't help now, last one was reverted
(12de375ec493ab1767d4a07dde823e63ae5edc21) in fact
it doesn't fix anything. So procesing interrupts in
kthread give us an opportunity to perform rescheduling
periodically.
Cc: Jiri Slaby
Signed-off-by: Denys Zagorui
work" messages
First one doesn't help now, last one was reverted
(12de375ec493ab1767d4a07dde823e63ae5edc21) in fact
it doesn't fix anything. So procesing interrupts in
kthread give us an opportunity to perform rescheduling
periodically.
Cc: Jiri Slaby
Signed-off-by: Denys Zagorui
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
t;too much work" messages
f4f653e9875e573860e783fecbebde284a8626f5
Last one was reverted later
12de375ec493ab1767d4a07dde823e63ae5edc21
So maybe we should redirect IRQ processing to
kthread and make this process more friendly for
other by rescheduling sometimes.
Best Regards,
Denys
On 10/31/
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
ate':
> >>>>>>
> >>>>>> /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/timers/posix_timers.c:157:
> >>>>>> undefined reference to `timer_create'
> >>>>>>
> >>>>&g
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 2017-04-03 15:09, Eric Dumazet wrote:
On Mon, 2017-04-03 at 11:10 +0300, Denys Fedoryshchenko wrote:
I modified patch a little as:
if (th->doff * 4 < sizeof(_tcph)) {
par->hotdrop = true;
WARN_ON_ONCE(!tcpinfo->option);
return false;
}
And it did triggered WARN once at
On 2017-04-02 20:26, Eric Dumazet wrote:
On Sun, 2017-04-02 at 10:14 -0700, Eric Dumazet wrote:
Could that be that netfilter does not abort earlier if TCP header is
completely wrong ?
Yes, I wonder if this patch would be better, unless we replicate the
th->doff sanity check in all netfilter
On 2017-04-02 15:32, Eric Dumazet wrote:
On Sun, 2017-04-02 at 15:25 +0300, Denys Fedoryshchenko wrote:
> */
I will add also WARN_ON_ONCE(tcp_hdrlen >= 15 * 4) before, for
curiosity, if this condition are triggered. Is it fine like that?
Sure.
It didnt triggered WARN_ON, and wit
On 2017-04-02 15:19, Eric Dumazet wrote:
On Sun, 2017-04-02 at 04:54 -0700, Eric Dumazet wrote:
On Sun, 2017-04-02 at 13:45 +0200, Florian Westphal wrote:
> Eric Dumazet wrote:
> > - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i +=
optlen(opt, i)) {
> > + for (i = si
On 2017-04-02 14:45, Florian Westphal wrote:
Eric Dumazet wrote:
- for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i +=
optlen(opt, i)) {
+ for (i = sizeof(struct tcphdr); i < tcp_hdrlen - TCPOLEN_MSS; i +=
optlen(opt, i)) {
if (opt[i] == TCPOPT_MSS && opt[i+1]
Repost, due being sleepy missed few important points.
I am searching reasons of crashes for multiple conntrack enabled
servers, usually they point to conntrack, but i suspect use after free
might be somewhere else,
so i tried to enable KASAN.
And seems i got something after few hours, and it l
I am not sure if it is same issue, but panics still happen, but much
less. Same server, nat.
I will upgrade to latest 4.10.x build, because for this one i dont have
files anymore (for symbols and etc).
[864288.511464] Modules linked in: nf_conntrack_netlink nf_nat_pptp
nf_nat_proto_gre xt_TCP
On 2017-02-18 09:42, Jon Masters wrote:
Hi Denys,
On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote:
After years of using kexec and recent unpleasant experience with
modern (supposed to be blazing fast to boot) hardware that need 5-10
minutes just to pass POST tests,
one question came up
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
From: Denys Dmytriyenko
As part of c11e391da2a8fe973c3c2398452000bed505851e "dma-buf: Add ioctls to
allow userspace to flush" a new uapi header file dma-buf.h was added, but an
entry was not added on Kbuild to install it. This patch resolves this omission
so that "make headers_in
Hello,
I noticed that sample of livepatch is not working in 4.9.9, because in
include,
linux/livepatch.h
it is:
#if IS_ENABLED(CONFIG_LIVEPATCH)
while config option is:
CONFIG_HAVE_LIVEPATCH=y
After editing livepatch.h sample module compiles fine
Probably that's just a typo?
Hello,
After years of using kexec and recent unpleasant experience with modern
(supposed to be blazing fast to boot) hardware that need 5-10 minutes
just to pass POST tests,
one question came up to me:
Is it possible anyhow to execute regular (not special "panic" one to
capture crash data) ke
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;
On 2017-01-11 19:22, Guillaume Nault wrote:
Cc: netfilter-de...@vger.kernel.org, I'm afraid I'll need some help
for this case.
On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote:
Hi,
I posted recently several netfilter related crashes, didn't got any
answer
Hi,
I posted recently several netfilter related crashes, didn't got any
answers, one of them started to happen quite often on loaded NAT
(17Gbps),
so after trying endless ways to make it stable, i found out that in
backtrace i can often see timers, and this bug probably appearing on
older rel
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
Hi,
Just attempted to upgrade from 4.8.10 to 4.9.10 with minimal kernel
changes (oldconfig, but then attempted to add few options to solve
problem (such as adding NR_CPUS and PCI options, didnt helped).
My filesystem are residing on USB drive, and USB where flash are located
is not working, so
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
1 - 100 of 1376 matches
Mail list logo
