Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1314319pxb; Fri, 13 Nov 2020 09:25:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJxzcQrui4uttm2Udzap8bPxl4DNrNflpCxRaZvlTSYll64f2/UID1oyuLZSTe8whzDqlbEq X-Received: by 2002:aa7:d443:: with SMTP id q3mr3723180edr.262.1605288305248; Fri, 13 Nov 2020 09:25:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605288305; cv=none; d=google.com; s=arc-20160816; b=Xa2c6ZmVb21w35GO7DCvFsYiexG+sJu1kxcvtiUbqOuxQiGj+ESSIr5K4jB6oQKose 9nxjqpGD8QFQcXFWNGNrYOoj0PPmrB5wVeIH4jAro8cvLzmrUMiSCPRnsBhLomM8+btR 1ZRq8SOfteFBQB7ItOphYgmGWXLUqBMVNPKQKqETkOY/Hcm0XeMqokn321/4tW0RpJXz izgEhUdvUSMrkI0ZdcBXj8OdItJCmjc9ngD/uoHuY+fk7mHN4njzDZ7fWIgSILiWJBRW xwexaxScYNJom8mWHVzqWQ6Ln48LNuj6AmArA3jBdrdGcCb7lVdJClrD/u6pOfL/DpxO edTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=dWizw0BnXf9qFxelpIMjmweUgHlumzIctWk/WTP0r9Q=; b=bZT2r6FO2p78O/kNMezuCFlLEMpf/KdBAx/FhPfN9NGdncmil76movFUNvRyu7HwB3 L3o2dI+uKrIhrmtyt+SuEvVzv0kaLfXiAO4bNxZAAztDlWxEGB7g68Frp/ZS4Qr92M4A mDMi47cBGDlj3XoqMPjjEQ9iVjrK0Z62FQvFbx4WvaH9QML1OEjVG6lrjsEKOjm6P9S1 nuKOvlZaxu2tJZRUHCDien+ZP9J/R44z6isc3XD5BSGLRRezZxHHk57gPuyUFQpWokbg 6rHEYV49SdnhCPJIndDPuIbcSTAN+zTm3R9qPnNRsLaLGolGZdMVsPT0NbzxD3ZYIzB0 2NBw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qc4si6115176ejb.188.2020.11.13.09.24.40; Fri, 13 Nov 2020 09:25:05 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726200AbgKMRVB (ORCPT + 99 others); Fri, 13 Nov 2020 12:21:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:58540 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726166AbgKMRU7 (ORCPT ); Fri, 13 Nov 2020 12:20:59 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 72459ABD9; Fri, 13 Nov 2020 17:21:11 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 643F2DA87A; Fri, 13 Nov 2020 18:19:28 +0100 (CET) Date: Fri, 13 Nov 2020 18:19:28 +0100 From: David Sterba To: Boqun Feng Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Filipe Manana , Peter Zijlstra , Jan Kara , David Sterba , Nikolay Borisov , "Darrick J. Wong" , Alexander Viro , Ingo Molnar Subject: Re: [RFC] fs: Avoid to use lockdep information if it's turned off Message-ID: <20201113171927.GG6756@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Boqun Feng , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Filipe Manana , Peter Zijlstra , Jan Kara , David Sterba , Nikolay Borisov , "Darrick J. Wong" , Alexander Viro , Ingo Molnar References: <20201110013739.686731-1-boqun.feng@gmail.com> <20201110153327.GL6756@suse.cz> <20201111140121.GN6756@suse.cz> <20201112032212.GF3025@boqun-archlinux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201112032212.GF3025@boqun-archlinux> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2020 at 11:22:12AM +0800, Boqun Feng wrote: > For the "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!" warning, do you see > that every time when you run xfstests and don't see other lockdep > splats? If so, that means we reach the limitation of number of lockdep > hlock chains, and we should fix that. It's not every time and depends on the release, eg. I found no reports in a sample log for 5.7..5.9, while there are many for 5.2..5.6 and 5.10, every 2nd or 3rd run. [ 0.185150] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.186202] ... MAX_LOCK_DEPTH: 48 [ 0.187286] ... MAX_LOCKDEP_KEYS: 8192 [ 0.188404] ... CLASSHASH_SIZE: 4096 [ 0.189519] ... MAX_LOCKDEP_ENTRIES: 32768 [ 0.190672] ... MAX_LOCKDEP_CHAINS: 65536 [ 0.191814] ... CHAINHASH_SIZE: 32768