From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751111AbdK3Hr2 (ORCPT ); Thu, 30 Nov 2017 02:47:28 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:33266 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbdK3Hr0 (ORCPT ); Thu, 30 Nov 2017 02:47:26 -0500 Date: Thu, 30 Nov 2017 08:47:18 +0100 From: Peter Zijlstra To: Daniel Vetter Cc: LKML , Ingo Molnar , Thomas Gleixner , Intel Graphics Development , Tejun Heo , Kees Cook , Tvrtko Ursulin , Marta Lofstedt , Daniel Vetter Subject: Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Message-ID: <20171130074718.hzed67wrwjtv4byu@hirez.programming.kicks-ass.net> References: <20171129154145.26755-1-daniel.vetter@ffwll.ch> <20171129154145.26755-3-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129154145.26755-3-daniel.vetter@ffwll.ch> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote: > cross-release ftl > > From Chris: > > "Fwiw, this isn't cross-release but us reloading the module many times, > creating a whole host of new lockclasses. Even more fun is when the > module gets a slightly different address and the new lock address hashes > into an old lock... Yeah, this is a known issue, just reboot. > "I did think about a module-hook to revoke the stale lockclasses, but > that still leaves all the hashed chains. Its an absolute royal pain to remove all the resources consumed by a module, and if you manage you then have to deal with fragmented storage -- that is, we need to go keep track of which entries are used. Its a giant heap of complexity that's just not worth it. Given all that, I don't see why we should up this. Just don't reload modules (or better, don't use modules at all).