c
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+5f97459a05652f579...@syzkaller.appspotmail.com
rash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5f97459a05652f579...@syzkaller.appspotmail.com
>
> BUG: MAX_STACK_TRACE_ENTRIES too low!
> turning off the locking correctness validator.
> CPU: 0 PID: 2581 Comm:
+5f97459a05652f579...@syzkaller.appspotmail.com
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 2581 Comm: kworker/u4:4 Not tainted 5.3.0-rc3+ #132
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns
On 7/12/19 1:55 AM, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote:
On 7/10/19 3:09 PM, Peter Zijlstra wrote:
One thing I mentioned when Thomas did the unwinder API changes was
trying to move lockdep over to something like stackdepot.
We can't directly
On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote:
> On 7/10/19 3:09 PM, Peter Zijlstra wrote:
> > One thing I mentioned when Thomas did the unwinder API changes was
> > trying to move lockdep over to something like stackdepot.
> >
> > We can't directly use stackdepot as is, because
if (!debug_locks_off_graph_unlock())
- return 0;
+ return NULL;
print_lockdep_off("BUG: MAX_STACK_TRACE_ENTRIES too low!");
dump_stack();
- return 0;
+ return NULL;
On Wed, Jul 10, 2019 at 02:23:39PM -0700, Bart Van Assche wrote:
> As one can see in remove_class_from_lock_chain() there is already code
> present in lockdep for compacting the chain_hlocks[] array. Similar code
> is not yet available for the stack_trace[] array because I had not
> encountered
On 7/10/19 1:47 PM, Eric Dumazet wrote:
>
>
> On 7/10/19 9:09 PM, Bart Van Assche wrote:
>> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>>> If anything using workqueues in dynamically allocated objects can turn off
>>> lockdep,
>>> we have a serious issue.
>>
>> As far as I know that issue is only
On 7/10/19 9:09 PM, Bart Van Assche wrote:
> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>> If anything using workqueues in dynamically allocated objects can turn off
>> lockdep,
>> we have a serious issue.
>
> As far as I know that issue is only hit by syzbot tests.
> Anyway, I see
> two
On 7/10/19 11:44 AM, Eric Dumazet wrote:
> If anything using workqueues in dynamically allocated objects can turn off
> lockdep,
> we have a serious issue.
As far as I know that issue is only hit by syzbot tests. Anyway, I see
two possible paths forward:
* Revert the patch that makes workqueues
On 7/10/19 8:36 PM, Bart Van Assche wrote:
> On 7/10/19 11:02 AM, Eric Biggers wrote:
>> I already mentioned that io_uring triggers it too.
>>
>> Those are just 2 cases that syzbot happened to generate reproducers for. I
>> expect there are many others too, since many places in the kernel
On 7/10/19 11:02 AM, Eric Biggers wrote:
> I already mentioned that io_uring triggers it too.
>
> Those are just 2 cases that syzbot happened to generate reproducers for. I
> expect there are many others too, since many places in the kernel allocate
> workqueues. AFAICS most are placed in
;locking/lockdep:
> > Shrink
> > struct lock_class_key"), I see instead:
> >
> > BUG: MAX_STACK_TRACE_ENTRIES too low!
> >
> > I also see that on mainline.
> >
> > Alternatively, if I check out 669de8bda87b and revert it, I don't see
> > anything.
80
>
> and then somewhat later:
>
> BUG: MAX_LOCKDEP_KEYS too low!
>
> If on top of that I cherry pick commit 28d49e282665 ("locking/lockdep: Shrink
> struct lock_class_key"), I see instead:
>
> BUG: MAX_STACK_TRACE_ENTRIES too low!
>
> I also s
x/repro.syz?x=10e1bacd20
> > > > > C reproducer:
> > > > > https://syzkaller.appspot.com/x/repro.c?x=1120fe0f20
> > > > >
> > > > > Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
> > > > >
> > > https://syzkaller.appspot.com/x/repro.syz?x=10e1bacd20
> > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1120fe0f20
> > > >
> > > > Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
> > > > F
ckdep keys for
workqueues")
For information about bisection process see:
https://goo.gl/tpsmEJ#bisection
Hi Dmitry,
This bisection result doesn't make sense to me. As one can see, the message
"BUG: MAX_STACK_TRACE_ENTRIES too low!" does not occur in the console output
the abov
.com/x/repro.c?x=1120fe0f20
> >
> > Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
> > Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
> > workqueues")
> >
> > For information about bisection process see:
> >
ne can see, the
message "BUG: MAX_STACK_TRACE_ENTRIES too low!" does not occur in the
console output the above console output URL points at.
Bart.
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f1bacd20
start
=12611c7320
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 678 Comm: syz-executor519 Not tainted 5.1.0
+6f39a9deb697359fe...@syzkaller.appspotmail.com
XFS (loop4): Invalid superblock magic number
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 1067 Comm: syz-executor.4 Not tainted 5.1.0-rc2+ #40
Hardware name: Google Google Compute Engine/Google Compute Engine
On Mon, 2019-03-11 at 10:48 -0700, Linus Torvalds wrote:
> On Mon, Mar 11, 2019 at 8:19 AM Bart Van Assche wrote:
> >
> > I think this issue has been fixed by a commit that went upstream yesterday.
> > Hence:
> >
> > #syz fix: workqueue, lockdep: Fix an alloc_workqueue() error path
>
> Well,
On Mon, Mar 11, 2019 at 8:19 AM Bart Van Assche wrote:
>
> I think this issue has been fixed by a commit that went upstream yesterday.
> Hence:
>
> #syz fix: workqueue, lockdep: Fix an alloc_workqueue() error path
Well, syzbot just reported a problem with that fix itself ("WARNING in
On Mon, 2019-03-11 at 06:26 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
> Author: Bart Van Assche
> Date: Thu Feb 14 23:00:54 2019 +
>
> kernel/workqueue: Use dynamic lockdep keys for workqueues
>
> bisection log:
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17dec75720
start
unately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+78923eea7cf44364f...@syzkaller.appspotmail.com
>
> BUG: MAX_STACK_TRACE_ENTRIES too low!
> turning off the locking correctne
: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+78923eea7cf44364f...@syzkaller.appspotmail.com
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 1176 Comm: kworker/u5:0 Not tainted 5.0.0-rc8-next-20190301 #1
+78923eea7cf44364f...@syzkaller.appspotmail.com
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
CPU: 0 PID: 19385 Comm: syz-executor.0 Not tainted 5.0.0-rc8-next-20190301
#1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call
On Sun, 27 Jan 2013 at 14:56, Christian Kujau wrote:
> Hm, is there no chance to get this into 3.8? I've been running with this
> patch applied since 3.7-rc7 and it got rid of this
> "MAX_STACK_TRACE_ENTRIES too low" message. I've just upgraded to 3.8-rc5
> and it's still not in mainline :-\
On Sun, 27 Jan 2013 at 14:56, Christian Kujau wrote:
Hm, is there no chance to get this into 3.8? I've been running with this
patch applied since 3.7-rc7 and it got rid of this
MAX_STACK_TRACE_ENTRIES too low message. I've just upgraded to 3.8-rc5
and it's still not in mainline :-\
Hah! I
0EP_ERR42
> > > ==========
> > >
> > > >
> > > > Christian.
> > > >
> > > > > [40007.339487] [sched_delayed] sched: RT throttling activated
> > > > > [69731.38871
schedule_tail
+ li r3,0
+ stw r3,0(r1)
mtlrr14
mr r3,r15
PPC440EP_ERR42
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too
t_from_fork:
> > ret_from_kernel_thread:
> > REST_NVGPRS(r1)
> > bl schedule_tail
> > + li r3,0
> > + stw r3,0(r1)
> > mtlrr14
> > mr r3,r15
> > PPC440EP_ERR42
> > ==
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525] [c9a61c10] [c0009064] show_stack
li r3,0
> + stw r3,0(r1)
> mtlrr14
> mr r3,r15
> PPC440EP_ERR42
> ==
>
> >
> > Christian.
> >
> > > [40007.339487] [sched_delayed] sched: RT throttling activated
&g
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525] [c9a61c10] [c0009064] show_stack
ork:
> > ret_from_kernel_thread:
> > REST_NVGPRS(r1)
> > bl schedule_tail
> > + li r3,0
> > + stw r3,0(r1)
> > mtlr r14
> > mr r3,r15
> > PPC440EP_ERR42
> > =
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525] [c9a61c10] [c0009064] show_stack+0x70/0x1bc
_from_fork:
> ret_from_kernel_thread:
> REST_NVGPRS(r1)
> bl schedule_tail
> + li r3,0
> + stw r3,0(r1)
> mtlrr14
> mr r3,r15
> PPC440EP_ERR42
> ==========
>
> >
&g
+ stw r3,0(r1)
mtlrr14
mr r3,r15
PPC440EP_ERR42
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off
again - or
not, now with your patch applied.
It happened only 2 times so far, after ~8h and after ~20h:
Nov 5 13:28:20 alice kernel: [0.00] Linux version 3.7.0-rc4
Nov 5 21:00:26 alice kernel: [27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too
low!
Nov 26 21:53:43 alice kernel: [0.00]
bl schedule_tail
+ li r3,0
+ stw r3,0(r1)
mtlrr14
mr r3,r15
PPC440EP_ERR42
==
>
> Christian.
>
> > [40007.339487] [sched_delayed] sched: RT throttling activated
> &
+ li r3,0
+ stw r3,0(r1)
mtlrr14
mr r3,r15
PPC440EP_ERR42
==
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low
- or
not, now with your patch applied.
It happened only 2 times so far, after ~8h and after ~20h:
Nov 5 13:28:20 alice kernel: [0.00] Linux version 3.7.0-rc4
Nov 5 21:00:26 alice kernel: [27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too
low!
Nov 26 21:53:43 alice kernel: [0.00] Linux
414/
It looks related, but then again, I fail to parse assember...
Christian.
> [40007.339487] [sched_delayed] sched: RT throttling activated
> [69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
> [69731.390371] turning off the locking correctness validator.
> [69731.391942] Call Trace:
Hi,
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525] [c9a61c10
Hi,
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525] [c9a61c10
/
It looks related, but then again, I fail to parse assember...
Christian.
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525
Hi,
after upgrading from 3.6.0-08492-gd43 to 3.7.0-rc4 and running it for a
day or so, this happened:
[27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too low!
[27148.967356] turning off the locking correctness validator.
[27148.968967] Call Trace:
[27148.970577] [ec633d00] [c0009064] show_stack
Hi,
after upgrading from 3.6.0-08492-gd43 to 3.7.0-rc4 and running it for a
day or so, this happened:
[27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too low!
[27148.967356] turning off the locking correctness validator.
[27148.968967] Call Trace:
[27148.970577] [ec633d00] [c0009064] show_stack
51 matches
Mail list logo
