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.
>
&g
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);
Previously
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:
> 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 edfd9b7838ba5e
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 pa
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 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
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
arch/x86/kernel/unwind_orc.c:
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.
W
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
all stack
> accesses. 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 Babr
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
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 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
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:
> > > >
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
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
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
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: ksoftirqd/
2]builtin-help.c:187:15: note: length computed here
[07: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 Babro
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: ve
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 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 wrote
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 A
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
26 matches
Mail list logo
