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
| ||
|
Date: Mon, 1 Feb 2021 22:24:14 +0900 From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> To: Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Dmitry Vyukov <dvyukov@...gle.com> Subject: Re: [PATCH v4 (resend)] lockdep: Allow tuning tracing capacity constants. Hello, Andrew and Linus. We are stuck because Peter cannot respond. I think it is time to send this patch to linux-next. What do you think? On 2021/01/20 19:18, Dmitry Vyukov wrote: > On Wed, Jan 20, 2021 at 11:12 AM Tetsuo Handa > <penguin-kernel@...ove.sakura.ne.jp> wrote: >> >> Since syzkaller continues various test cases until the kernel crashes, >> syzkaller tends to examine more locking dependencies than normal systems. >> As a result, syzbot is reporting that the fuzz testing was terminated >> due to hitting upper limits lockdep can track [1] [2] [3]. >> >> Peter Zijlstra does not want to allow tuning these limits via kernel >> config options, for such change discourages thinking. But analysis via >> /proc/lockdep* did not show any obvious culprit [4] [5]. It is possible >> that many hundreds of kn->active lock instances are to some degree >> contributing to these problems, but there is no means to verify whether >> these instances are created for protecting same callback functions. >> Unless Peter provides a way to make these instances per "which callback >> functions the lock instance will call (identified by something like MD5 >> of string representations of callback functions which each lock instance >> will protect)" than plain "serial number", I don't think that we can >> verify the culprit. >> >> [1] https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b >> [2] https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a >> [3] https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29f >> [4] https://lkml.kernel.org/r/4b8f7a57-fa20-47bd-48a0-ae35d860f233@i-love.sakura.ne.jp >> [5] https://lkml.kernel.org/r/1c351187-253b-2d49-acaf-4563c63ae7d2@i-love.sakura.ne.jp >> >> Reported-by: syzbot <syzbot+cd0ec5211ac07c18c049@...kaller.appspotmail.com> >> Reported-by: syzbot <syzbot+91fd909b6e62ebe06131@...kaller.appspotmail.com> >> Reported-by: syzbot <syzbot+62ebe501c1ce9a91f68c@...kaller.appspotmail.com> >> Signed-off-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> >> Acked-by: Dmitry Vyukov <dvyukov@...gle.com> > > Thanks for your persistence! > I still support this. And assessment of lockdep stats on overflow > seems to confirm it's just a very large lock graph triggered by > syzkaller. >
Powered by blists - more mailing lists