Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8008182ybl; Thu, 16 Jan 2020 09:08:11 -0800 (PST) X-Google-Smtp-Source: APXvYqxA7XBR52hKCgSjzDaWc715AFoXRTWh6AUv8KPyTWE25Qo8ItkrGtjH4N7ZSanfspHkP2XR X-Received: by 2002:a9d:7ac9:: with SMTP id m9mr2737936otn.80.1579194491196; Thu, 16 Jan 2020 09:08:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579194491; cv=none; d=google.com; s=arc-20160816; b=ROYv8u6PxjKwbWJ2b8cMba9TCXAT5Rqi50ru1iYtBJVp7kqixGgwgNkCNgJdngeWbT nHH22oCC+NYDFCtMNoc9m3Jtzxw++tvViEjAW8qYfz4ds0nQ/UY+XKNduCduiNeCdnEv 97M5E5KV+H/rQK1Kb9zGrPBbkg/DdGUw9BHisI9prWCwP0bt+u5W76P0fgu4Lfk8G9Bb 1GHuLvjzRY1drY4VEjnMjp5w4in6Q4Tly+wxIS/WWmX2WMXGGdL6Xdb3/CUGX5nL9nve 1HNEzV1ACu6XH9WkiXr+eiYsjKok67pt2vE+dYImg0ehNnjZaXb8U920Ut/XFO5WnD/c pcmQ== 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=RCX1DjLcpjcGUAoMpV6YYMWCiBCtakKXdZrlVb3Tyy8=; b=JNa7vLkxEGmmJt+5zXs5oBJpirDvnqsnxBxJTYlm+d1ae0KZ3VXpjb9W1fvKbnz2uQ Mq7VbezM0QtAXDnn8R+4FAQy8auGeFLw+wFZ0y2WzExZLAic8REmc59EnE42rCIoV2mk oXdVXUfxQFiknXx8+yYVZleZQRvTNuWrdz/YK3hTALpUvxpyvW+QKpwfFrc9cGlhC2J7 6M611UieMbl2696P01HcdWXTYaoprtRJXInLsvjsch4gqO9ETrgYZ1ZJunPEyjVYmrCF nEYgRdtnmYwFaADTVFet4pPKjLUNWq7gaDoJdnot8pTKBsE4uBGeu9Gkxct1W2UeNfh0 IcRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=S1T1m6ho; 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 i12si13402250otk.215.2020.01.16.09.07.58; Thu, 16 Jan 2020 09:08:11 -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=S1T1m6ho; 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 S2388547AbgAPRFx (ORCPT + 99 others); Thu, 16 Jan 2020 12:05:53 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:33249 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388668AbgAPRFk (ORCPT ); Thu, 16 Jan 2020 12:05:40 -0500 Received: by mail-qk1-f194.google.com with SMTP id d71so19817867qkc.0 for ; Thu, 16 Jan 2020 09:05:39 -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=RCX1DjLcpjcGUAoMpV6YYMWCiBCtakKXdZrlVb3Tyy8=; b=S1T1m6ho4sRqkMHKBW/4e5n523sCceKbTikflTeOEt4Ig55bKYwBg0WI/OOe/h9fmL ia8pZQExSIupL6JVJ+sDLATnarRN9Rwp2oQ4NU2Q9aWpDTPQlzwTuiL9oSdZh9+TJny9 Fi0sAVNH2N7CVKMj2EGMsU/C3E5Vbwx0YOx1YEPSh+bgapvW27Cadwyn3lT6o7zFCw5Q nvSRsUX03Go7jC5R4TS/y+HxUP9kruyRp+YLnoG1Hzoo8RAUmDT4avJQ+w0m+zgrH9pS Xq8zuCv1XgzqPMRIwjxWDWulmtxO/jJyBGhWIlVuZyN14e3Ky5VMKrKyUxnuNsP6rs6X Tqag== 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=RCX1DjLcpjcGUAoMpV6YYMWCiBCtakKXdZrlVb3Tyy8=; b=bPShq2L5UPxiw0H3L8irRnybwcda1mPmkdJTVzjNGe3zj2tX0K1fpVNQkodZ5Y0l6y f0XzG65q3nWfBHDvgPAwVNUYGFAOi8aLBT2fD2ElaRWIjr+z0Zg06bBVq0qaGRfKs1/i /fi5WQD8peXoJLqDN7rRHfXww2U/3eIBhdzGOlvXM6KbLNcY69BhG2kwxXPdv8gz9xWj DLGUuBJNQoo7G5BvDmdo7Kl0P7p/8UcRUca8VMDzOlDPzmrXqT+qe50WRyyGND0dRVAF oPO9IYtEvfLHgidmeBYPdwzjz6gTbA1IcOS3fz/YxZmbJO92zwcREQvqrmRbapPNFZ+V OsWw== X-Gm-Message-State: APjAAAVB0Vm8dYyQdg38TsmqsD4E/zjj4x7jMEF3xb2lugoqAw3ryVMh B19ESt3ignhPCeX2L8KIwvzBBQXtzTuJFuziN4EPSA== X-Received: by 2002:a37:5841:: with SMTP id m62mr33034639qkb.256.1579194339123; Thu, 16 Jan 2020 09:05:39 -0800 (PST) MIME-Version: 1.0 References: <0000000000007523a60576e80a47@google.com> <20180928070042.GF3439@hirez.programming.kicks-ass.net> In-Reply-To: From: Dmitry Vyukov Date: Thu, 16 Jan 2020 18:05:26 +0100 Message-ID: Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low! To: Taehee Yoo Cc: Cong Wang , Peter Zijlstra , 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 16, 2020 at 4:33 PM Taehee Yoo wrote: > > On Thu, 16 Jan 2020 at 14:25, Dmitry Vyukov wrote: > > > > Hi Dmitry! > > > On Wed, Jan 15, 2020 at 10:53 PM Cong Wang wrote: > > > > +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? > > > > > > Very possibly. In current code base, there are 4 lockdep keys > > > per netdev: > > > > > > struct lock_class_key qdisc_tx_busylock_key; > > > struct lock_class_key qdisc_running_key; > > > struct lock_class_key qdisc_xmit_lock_key; > > > struct lock_class_key addr_list_lock_key; > > > > > > so the number of lockdep keys is at least 4x number of network > > > devices. > > > > And these are not freed/reused, right? So with dynamic keys LOCKDEP > > inherently can't handle prolonged running, only O(1) work? > > When netdev interface is removed, these dynamic keys are removed. > But if so many netdev interfaces are existing concurrently > (more than 2000), lockdep will stop because of a lack of keys. > In addition, as far as I know, freeing dynamic lockdep key routine is > slower than creating a new dynamic lockdep key. If there are so many > netdev interface add/delete operations, for a while, there may be no > available lockdep key. At this moment, lockdep will stop. > > Thank you > Taehee Yoo This issues mostly stalled all syzbot testing by now, these LOCKDEP bugs are the only bugs that are being detected... 2020/01/16 15:30:47 vm-2: crash: BUG: MAX_LOCKDEP_ENTRIES too low! 2020/01/16 15:38:28 vm-3: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! 2020/01/16 15:39:55 vm-0: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! 2020/01/16 15:41:19 vm-6: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! 2020/01/16 15:41:35 vm-1: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! 2020/01/16 15:51:16 vm-2: crash: BUG: MAX_LOCKDEP_ENTRIES too low! 2020/01/16 15:57:52 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low! 2020/01/16 16:00:57 vm-6: crash: BUG: MAX_LOCKDEP_ENTRIES too low! 2020/01/16 16:36:35 vm-1: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! 2020/01/16 16:37:04 vm-3: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!