Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp582956pxk; Wed, 16 Sep 2020 11:22:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDW9QqL4iXdptFEfe2GmCProVQHwdfYVI08neKRcCuZ9GWZMlXgF+zjPcPKsFUF84YhlOU X-Received: by 2002:a17:906:aec1:: with SMTP id me1mr9901883ejb.225.1600280575236; Wed, 16 Sep 2020 11:22:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600280575; cv=none; d=google.com; s=arc-20160816; b=M69ziW5aO51/xAGIAfqfNO5mo08+Juib4dJup6rdVi6D5kHOL9WuBvcgvz8Lvpbnyc elyhprAr2TkiXSld2s8gi+4PiZijUugNQHdI9LaIlTIdgnPo07wBEKu6KMWIWWDsSwRQ SA2wPnDDZdYP+MGVLDvqOAr7AQnxM85WrMf7VeVkZhWLGFvUkWwSigGYNJzPdmhbc7o7 Sn9U5r4qkaOxqU4Ub4rSWZyH70KaKkQFyVj+OZwVym1eRpavJII5/hwGmfBtE1Tm2Ddq HqU1UULqxVoozrbMsA6vxq/fy07FaMYolwiCgB7xrm6Tq+xZ/iuBInSclgC7FsgYOQVd EFIw== 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=3Xbnktyhb9WFDAxiYS4WBTdEl5zwV8oooRagE02H28Q=; b=MWKwkl7WFwMthCQQwMHD4l1Z4BmhJ6tcEu7XB8bTKmcmHb/N6b8sSpZ0f9Wqmr0gEf 8dSCcHNtOCTq1YmPVH/qN2Vgb6ry5ESnnQUm4bVtj9CJGmJRnF3EONfbSpOAW1ao0JOA IvEOreEQFmFrZ0cWCPCrPY17szHUft1OF8W6ZN4t1TGbLC7fz91IsWoENK0YF08G3ZeG 1Ed6E0fQOse1E34c9wcaPw3eqcGS2eU0SwGkjgI2QqkRtGf0eYN2zyzN7JDoV6+zyBIF 1wPgfBH8xUpcM2feogwkt0SWWpGgFaHOe9/x5O5KTi1/2P7SM6B5p5grv6LUDN2acpdC bKHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=O9iue7DF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id l21si11892816edq.277.2020.09.16.11.22.32; Wed, 16 Sep 2020 11:22:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=O9iue7DF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727926AbgIPSVy (ORCPT + 99 others); Wed, 16 Sep 2020 14:21:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727781AbgIPSJR (ORCPT ); Wed, 16 Sep 2020 14:09:17 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1542FC02B8C2 for ; Wed, 16 Sep 2020 05:14:15 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id b2so1159696qtp.8 for ; Wed, 16 Sep 2020 05:14:15 -0700 (PDT) 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=3Xbnktyhb9WFDAxiYS4WBTdEl5zwV8oooRagE02H28Q=; b=O9iue7DFM0C0fMvpQTb/en9DF5Peqm1IRWDZ/2HLqA3NAMA4dplbaveetPHUNKbI2B hHXo1npQenyDC/Jes0H08n83h8MpUodySpfwjlIh9cTrsx39P+KxRosDsNcj/yY4kEiS FifgLyPzzII2OBnnF5z5X86ELPHY1JlsTlfIz8stfbLcaK7RxN1WzbifRuk8xVMQo9oL O7XhaaMzzq3TqpoIAs7YZAGaslFDeMJD+Hh57gIVzzScSpEgcv5mkcNhtyaIyp8SGYQT iJWNMDWyvTShNWoE38x3LEitrberwD3B3UFfHHX4/q8Km9BStX0KqYOXhBW9zIwqKmYg hyWQ== 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=3Xbnktyhb9WFDAxiYS4WBTdEl5zwV8oooRagE02H28Q=; b=KNsxpoMmEV8jRBRosp+0zvAo1cG96CzUV8tJZjiRbAj605gNgcertpBAxiXLtlxaYX Dlc5RIhqATuMcfwCOC7zJmZYSq077ySPqeNo49nMn2eoV+7ZkU83vLv6noWGgb5h+xt4 GzWSlf+uuvNajYriPl4KcpSORRO7mBeOQH0Hvh7Ka00bMKdKFuTVGw1kxgv9U2aVL468 EpQmi86kjQDZ43ZGO8XGjn8JN34yS89CMxInuFz4uz2b1MW0+Wzrc9ckJi0Pfqmj6U8Q dMDlDxQWeRMxpMHR+gteZBXOIOwsk58sHiOCLTO28NXq1ZDnrL2ab4cxh6Apkm9Pz8Ua VM3g== X-Gm-Message-State: AOAM5323dmWyMzCoZpQJevzNHCe9sNRdoXLsJMnvCgMCDcbgYpIPHkxm SK38CiM4AviYs+5SOZFdkvPIM5J37N2Ne0YDPyyyPQ== X-Received: by 2002:aed:26a7:: with SMTP id q36mr22023441qtd.57.1600258454063; Wed, 16 Sep 2020 05:14:14 -0700 (PDT) MIME-Version: 1.0 References: <1595640639-9310-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <384ce711-25c5-553b-8d22-965847132fbd@i-love.sakura.ne.jp> <0f7233f7-a04a-e9c9-7920-3a170cc97e4b@i-love.sakura.ne.jp> <20200916115057.GO2674@hirez.programming.kicks-ass.net> In-Reply-To: <20200916115057.GO2674@hirez.programming.kicks-ass.net> From: Dmitry Vyukov Date: Wed, 16 Sep 2020 14:14:02 +0200 Message-ID: Subject: Re: [PATCH v2] lockdep: Allow tuning tracing capacity constants. To: Peter Zijlstra Cc: Tetsuo Handa , Ingo Molnar , Will Deacon , Andrew Morton , LKML , syzkaller 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 Wed, Sep 16, 2020 at 1:51 PM wrote: > > On Wed, Sep 16, 2020 at 01:28:19PM +0200, Dmitry Vyukov wrote: > > On Fri, Sep 4, 2020 at 6:05 PM Tetsuo Handa > > wrote: > > > > > > Hello. Can we apply this patch? > > > > > > This patch addresses top crashers for syzbot, and applying this patch > > > will help utilizing syzbot's resource for finding other bugs. > > > > Acked-by: Dmitry Vyukov > > > > Peter, do you still have concerns with this? > > Yeah, I still hate it with a passion; it discourages thinking. A bad > annotation that blows up the lockdep storage, no worries, we'll just > increase this :/ > > IIRC the issue with syzbot is that the current sysfs annotation is > pretty terrible and generates a gazillion classes, and syzbot likes > poking at /sys a lot and thus floods the system. > > I don't know enough about sysfs to suggest an alternative, and haven't > exactly had spare time to look into it either :/ > > Examples of bad annotations is getting every CPU a separate class, that > leads to nr_cpus! chains if CPUs arbitrarily nest (nr_cpus^2 if there's > only a single nesting level). Maybe on "BUG: MAX_LOCKDEP_CHAINS too low!" we should then aggregate, sort and show existing chains so that it's possible to identify if there are any worst offenders and who they are. Currently we only have a hypothesis that there are some worst offenders vs lots of normal load. And we can't point fingers which means that, say, sysfs, or other maintainers won't be too inclined to fix anything. If we would know for sure that lock class X is guilty. That would make the situation much more actionable.