Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3818915ybl; Mon, 13 Jan 2020 03:12:54 -0800 (PST) X-Google-Smtp-Source: APXvYqxvCG58AWaZ1Wy4WDOpG4Fbz2eyyS+KYG+xnClh0rTix67EisSL+dC7pGGcEojyd14mPbX6 X-Received: by 2002:a05:6830:108a:: with SMTP id y10mr12696782oto.81.1578913973988; Mon, 13 Jan 2020 03:12:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578913973; cv=none; d=google.com; s=arc-20160816; b=ORvtuhUooeuxLBDLPrkB+U2OV5tLwlB8GUK3PWDOzVW56L33t0+JYuQlWXbhztXC0K wCwLRhwNOMjdTqN0ext/0gdLmgetqpf/LuFjgHbcPioWMmRGdWu+ojPZ7OMY29vB7F1n XBGOvRaATDfsqXGIE+I1fmp12oCHTUkybI/3/bltlgLYes1qxZ1C4rTCETJFKngH01hq KbV5zw0nz1OsH0Ms13WdFK5pOSpeGo5q3XW9dI73myumMasSR+5hOIaUTtkzb3BU4AVy bEnxzfICa+cBsmUiRyJD6kmQSST37enk9NtDW54zVEOgjYtIe8PgliPAtDeXylWHpbrU cpBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=pwo6CXoEExY4P7FhgrfOA4x+oRv3QDj7HzIdYTSbXyQ=; b=ZJyC+oax1rQNK8hqKPFZyFUKXpOMhkXSdsJl2oHFzxjXSJsGzkW8DUuVWS6ss/YdRF 4uUlQ6h3Xh2BMg8HmmJ2trkrnKg5Vp7A/wkTFqUoiizH2PTkSNkRjNqp1gP40zbH3QJg b0Ouu1oXp48UUULZFTypD4q7WM68XoOygfFUpg2HDHNbp69FU+1TDjjDQaFytX+1FXZt bfGBobGYqbxU8bq6XLXAgrYznhjTS3p7cXF8E4XCGJhAlkYhSMz8x72yyefpeIbaV32a wrU8pyJU7ih59oERQwxAlROf73xGKQ19ShYz5b3xjPvaOwUQgObiDOLzRB0Uf858c63y uDDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GUJkBVdz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w26si5899401otl.213.2020.01.13.03.12.41; Mon, 13 Jan 2020 03:12:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GUJkBVdz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728721AbgAMLLg (ORCPT + 99 others); Mon, 13 Jan 2020 06:11:36 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:44458 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbgAMLLg (ORCPT ); Mon, 13 Jan 2020 06:11:36 -0500 Received: by mail-qt1-f196.google.com with SMTP id t3so8703441qtr.11 for ; Mon, 13 Jan 2020 03:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pwo6CXoEExY4P7FhgrfOA4x+oRv3QDj7HzIdYTSbXyQ=; b=GUJkBVdzgnMf0uZMhvQz3acAlzbV4FMyCI7t0kYp7G0i+Sezxl6ysPMtzU9CleaPK7 zzh8GYSESpFS4ifdi5j4tEHfKKTulXLoGcUk4plZuV427yJNjbLcluLDNjwj9YY1IEVR nXb/DRj9QH44Xc4QntHxM6ZCC7GEA2O1xYUDTvnC7GmsxDthlnAr9r+OKFVROOMbbXSk gI4XGR2Ah05yNxJFZwONuA6MlPHQfodqMoLlxZPQRr75St9qUTfOt9jPyaxGELAipg6C N0R3z2PqY9wO10Xk2x2y0rarFJMVTbyBpGw7T/f2UlQiDQlxNDJzy7LwUrMkVB/Lkk9q Ye/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pwo6CXoEExY4P7FhgrfOA4x+oRv3QDj7HzIdYTSbXyQ=; b=pvSWYd4ZdNErvqS/eFZGD7Wuxe9yYESOvNI2m+gI7brvficVWHOpHjjHLKbO6MzbtY Tq1xg71DXQXToUQ61loKLpBU7RkmVEys9XlKDDRPH5pQqGRiYYnWufkc5BcnlKCXefz6 nrt+/RgtQRezPnrFIQATT2gg/ura+xB2MWkXwMlHaEleVcsyrBcVYUdejWcEMi5qVRk1 t6T+6KFp87SaIzQzR7SoqzotpHSPBKSK8v8KQyf2a717YmhZDG/VO7phI+mMATN4uvH5 Kl0lzJBlNkaCHW58hxXUEf+1XfwAJwyI+1tHBmtFlIFbgT7DZXY7svkwvsvSC8IA7y4S u+hQ== X-Gm-Message-State: APjAAAW4iF5rymqm09OiISa6EtaYAU13WccCcgbdoOUrS7nzEDcXAndb rszi92+cjUZFOxttKMgGQ1/411FHVws0HjZUldQTLg== X-Received: by 2002:ac8:71d7:: with SMTP id i23mr13691627qtp.50.1578913894652; Mon, 13 Jan 2020 03:11:34 -0800 (PST) MIME-Version: 1.0 References: <0000000000007523a60576e80a47@google.com> <20180928070042.GF3439@hirez.programming.kicks-ass.net> In-Reply-To: From: Dmitry Vyukov Date: Mon, 13 Jan 2020 12:11:23 +0100 Message-ID: Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low! To: Peter Zijlstra , Cong Wang , ap420073@gmail.com Cc: syzbot , Ingo Molnar , Will Deacon , LKML , syzkaller-bugs , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 9, 2020 at 11:59 AM Dmitry Vyukov wrote: > > On Fri, Sep 28, 2018 at 9:56 AM Dmitry Vyukov wrote: > > >> > Hello, > > >> > > > >> > syzbot found the following crash on: > > >> > > > >> > HEAD commit: c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of git://gi.. > > >> > git tree: upstream > > >> > console output: https://syzkaller.appspot.com/x/log.txt?x=13810df1400000 > > >> > kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f > > >> > dashboard link: https://syzkaller.appspot.com/bug?extid=aaa6fa4949cc5d9b7b25 > > >> > compiler: gcc (GCC) 8.0.1 20180413 (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+aaa6fa4949cc5d9b7b25@syzkaller.appspotmail.com > > >> > > >> +LOCKDEP maintainers, > > >> > > >> What does this BUG mean? And how should it be fixed? > > >> > > >> Thanks > > >> > > >> > BUG: MAX_LOCKDEP_CHAINS too low! > > > > > > Is the his result of endlessly loading and unloading modules? > > > > > > In which case, the fix is: don't do that then. > > > > No modules involved, we don't have any modules in the image. Must be > > something else. > > Perhaps syzkaller just produced a workload so diverse that nobody ever produced. > > Peter, Ingo, > > This really plagues syzbot testing for more than a year now. These four: > > BUG: MAX_LOCKDEP_KEYS too low! > https://syzkaller.appspot.com/bug?id=8a18efe79140782a88dcd098808d6ab20ed740cc > > BUG: MAX_LOCKDEP_ENTRIES too low! > https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b > > BUG: MAX_LOCKDEP_CHAINS too low! > https://syzkaller.appspot.com/bug?id=bf037f4725d40a8d350b2b1b3b3e0947c6efae85 > > BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a > > > Now running testing I only see a stream of different lockdep bugs mostly: > > 2020/01/09 11:41:51 vm-13: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:43:09 vm-9: crash: INFO: task hung in register_netdevice_notifier > 2020/01/09 11:44:00 vm-26: crash: no output from test machine > 2020/01/09 11:44:11 vm-8: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:44:28 vm-19: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:46:20 vm-27: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:46:41 vm-15: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:46:45 vm-28: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:46:47 vm-29: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:46:49 vm-22: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:46:50 vm-10: crash: no output from test machine > 2020/01/09 11:46:52 vm-18: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:46:53 vm-23: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:47:17 vm-20: crash: lost connection to test machine > 2020/01/09 11:47:48 vm-5: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:47:56 vm-14: crash: WARNING in restore_regulatory_settings > 2020/01/09 11:48:19 vm-2: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:48:21 vm-7: crash: BUG: MAX_LOCKDEP_ENTRIES too low! > 2020/01/09 11:48:22 vm-3: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! > 2020/01/09 11:48:40 vm-25: crash: BUG: MAX_LOCKDEP_CHAINS too low! > > Should we just bump the limits there? > > Or are there some ID leaks in lockdep? syzbot has a bunch of very > simple reproducers for these bugs, so not really a maximally diverse > load. And I think I saw these bugs massively when testing just a > single subsystem too, e.g. netfilter. +Taehee, Cong, In the other thread Taehee mentioned the creation of dynamic keys for net devices that was added recently and that they are subject to some limits. syzkaller creates lots of net devices for isolation (several dozens per test process, but then these can be created and destroyed periodically). I wonder if it's the root cause of the lockdep limits problems?