linux-kernel - Re: BUG: MAX_STACK_TRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.