[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190710220943.GM3419@hirez.programming.kicks-ass.net>
Date: Thu, 11 Jul 2019 00:09:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
linux-kernel@...r.kernel.org,
syzbot <syzbot+6f39a9deb697359fe520@...kaller.appspotmail.com>,
syzkaller-bugs@...glegroups.com
Subject: Re: BUG: MAX_STACK_TRACE_ENTRIES too low! (2)
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 any overflows of that array during my tests.
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 it uses locks and memory
allocation, but we could maybe add a lower level API to it and use that
under the graph_lock() on static storage or something.
Otherwise we'll have to (re)implement something like it.
I've not looked at it in detail.
Powered by blists - more mailing lists