Hello,
We started seeing allocation failures on procfs reads after
commit 4bd6a7353ee1 "sysctl: Convert to iter interfaces".
I haven't done a full bisect, but the decoded stacks point
squarely at the following piece of code which was introduced:
kbuf = kzalloc(count + 1, GFP_KERNEL);
ils will
> > also be expected. So don't warn about it.
> >
> > Signed-off-by: Josh Poimboeuf
>
> Cc: sta...@vger.kernel.org
I was the one who asked for this to be backported, since it solved the
warnings for me.
Tested-by: Ivan Babrou
sses. This finishes the job started by commit 881125bfe65b
> ("x86/unwind: Disable KASAN checking in the ORC unwinder"), which only
> partially fixed the issue.
>
> Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder")
> Reported-by: Ivan Babrou
> Cc: sta...@
On Wed, Feb 3, 2021 at 4:17 PM Josh Poimboeuf wrote:
>
> On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > > Can you recreate with this patch, and add "unwind_debug" to the
> > > > > cmdline?
> > > > > It will spi
On Wed, Feb 3, 2021 at 7:10 PM Josh Poimboeuf wrote:
> This line gives a big clue:
>
> [160676.608966][C4] RIP: 0010:0xc17d814c
>
> That address, without a function name, most likely means that it was
> running in some generated code (mostly likely BPF) when it got
> interrupted.
On Wed, Feb 3, 2021 at 4:17 PM Josh Poimboeuf wrote:
>
> On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > > Can you recreate with this patch, and add "unwind_debug" to the
> > > > > cmdline?
> > > > > It will spi
On Wed, Feb 3, 2021 at 3:28 PM Josh Poimboeuf wrote:
>
> On Wed, Feb 03, 2021 at 02:41:53PM -0800, Ivan Babrou wrote:
> > On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
> > >
> > > On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > >
On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
>
> On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > Can you pretty please not line-wrap console output? It's unreadable.
> >
> > GMail doesn't make it easy, I'll send a link to a pastebin next tim
> Can you pretty please not line-wrap console output? It's unreadable.
GMail doesn't make it easy, I'll send a link to a pastebin next time.
Let me know if you'd like me to regenerate the decoded stack.
> > edfd9b7838ba5e47f19ad8466d0565aba5c59bf0 is the first bad commit
> > commit
On Thu, Jan 28, 2021 at 7:35 PM Ivan Babrou wrote:
>
> Hello,
>
> We've noticed the following regression in Linux 5.10 branch:
>
> [ 128.367231][C0]
> ==
> [ 128.368523][C0] BUG: KA
Hello,
We've noticed the following regression in Linux 5.10 branch:
[ 128.367231][C0]
==
[ 128.368523][C0] BUG: KASAN: stack-out-of-bounds in
unwind_next_frame (arch/x86/kernel/unwind_orc.c:371
processing:
sfc :86:00.0 ext0: XDP TX failed (-22)
Signed-off-by: Ivan Babrou
---
drivers/net/ethernet/sfc/efx_channels.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx_channels.c
b/drivers/net/ethernet/sfc/efx_channels.c
index
On Thu, Dec 17, 2020 at 10:14 AM Jakub Kicinski wrote:
>
> On Mon, 14 Dec 2020 17:29:06 -0800 Ivan Babrou wrote:
> > Without this change the driver tries to allocate too many queues,
> > breaching the number of available msi-x interrupts on machines
> > with many logical
On Thu, Jan 7, 2021 at 12:59 PM Thomas Renninger wrote:
>
> Am Donnerstag, 7. Januar 2021, 18:42:25 CET schrieb Ivan Babrou:
> > On Thu, Jan 7, 2021 at 2:07 AM Thomas Renninger wrote:
> > > Am Dienstag, 5. Januar 2021, 00:57:18 CET schrieb Ivan Babrou:
> > > &
On Thu, Jan 7, 2021 at 2:07 AM Thomas Renninger wrote:
>
> Am Dienstag, 5. Januar 2021, 00:57:18 CET schrieb Ivan Babrou:
> > This allows building cpupower in parallel rather than serially.
>
> cpupower is built serially:
>
> [ make clean ]
>
> time make
> re
This allows building cpupower in parallel rather than serially.
Signed-off-by: Ivan Babrou
---
tools/power/cpupower/Makefile | 8
tools/power/cpupower/bench/Makefile | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/power/cpupower/Makefile b/tools/power
processing:
sfc :86:00.0 ext0: XDP TX failed (-22)
Signed-off-by: Ivan Babrou
---
drivers/net/ethernet/sfc/efx_channels.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx_channels.c
b/drivers/net/ethernet/sfc/efx_channels.c
index
Hello,
We're seeing the following KASAN complaint on some nodes. These use
AMD CPUs and NVMe storage, and we don't see the same issue on older
Intel machines with SATA drives.
[Thu Jun 11 14:14:44 2020] systemd[1]: Detected architecture x86-64.
[Thu Jun 11 14:15:12 2020] device-mapper: uevent:
:15:32] 187 | size_t len = strlen(name);
[07:15:32] | ^~~~
[07:15:32]cc1: all warnings being treated as errors
On Fri, May 17, 2019 at 11:27 AM Arnaldo Carvalho de Melo
wrote:
>
> On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou wrote:
> >On Fri, May 17, 2019 at 8:22 AM Arna
On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> > On Fri, May 17, 2019 at 10:51 AM Greg KH wrote:
> > >
> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > > > On Fri, May 17, 2019 at 9:38
We are building the upstream kernel. There are a few patches, but
nothing related to objtool.
Unless you mean mainline/stable by upstream, I haven't tried that. We
stick to LTS.
On Thu, May 16, 2019 at 7:04 PM Josh Poimboeuf wrote:
>
> On Thu, May 16, 2019 at 11:20:54PM +0200, Miguel Ojeda
On Thu, May 16, 2019 at 2:21 PM Miguel Ojeda
wrote:
>
> Hi,
>
> On Thu, May 16, 2019 at 10:11 PM Ivan Babrou wrote:
> >
> > Hey Miguel,
> >
> > The first error is during perf build process (make -C tools/perf install):
> >
> > [17:38:21] In file
We're going to try this, but crashes are really infrequent and our
stack is slightly different:
* We have RIP = __srcu_read_unlock on x86_64
* Patch mentions PC = __srcu_read_lock on aarch64
On Wed, Jan 16, 2019 at 7:49 AM Greg KH wrote:
>
> On Tue, Jan 15, 2019 at 10:36:42AM -0800
Hey,
We've upgraded some machines from 4.14 to 4.19 and started seeing rare
crashes like these:
[75855.909507] BUG: unable to handle kernel NULL pointer dereference
at 0d00
[75855.925667] PGD 0 P4D 0
[75855.936359] Oops: [#1] SMP PTI
[75855.947951] CPU: 0 PID: 10 Comm:
On Wed, Nov 28, 2018 at 5:04 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, Nov 27, 2018 at 11:41:19PM -0800, Ivan Babrou escreveu:
> > Hey Arnaldo,
> >
> > Thanks for the quick response. I've tried your patch and it works as
> > expected with perf top.
>
> Ok
On Wed, Nov 28, 2018 at 5:04 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, Nov 27, 2018 at 11:41:19PM -0800, Ivan Babrou escreveu:
> > Hey Arnaldo,
> >
> > Thanks for the quick response. I've tried your patch and it works as
> > expected with perf top.
>
> Ok
Hello,
We're seeing unexpected CFS throttling. I wrote down detailed
description with an easily reproducible case here:
* https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1
TL;DR is that even though we don't burn through CFS quota during the
period, throttling kicks in anyways. The
Hello,
We're seeing unexpected CFS throttling. I wrote down detailed
description with an easily reproducible case here:
* https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1
TL;DR is that even though we don't burn through CFS quota during the
period, throttling kicks in anyways. The
28 matches
Mail list logo
