From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [BUG] lockdep splat with kernfs lockdep annotations and slab mutex from drm patch?? Date: Fri, 14 Jun 2019 08:38:37 -0700 Message-ID: <20190614153837.GE538958@devbig004.ftw2.facebook.com> References: <20190614093914.58f41d8f@gandalf.local.home> <156052491337.7796.17642747687124632554@skylake-alporthouse-com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <156052491337.7796.17642747687124632554@skylake-alporthouse-com> Sender: linux-kernel-owner@vger.kernel.org To: Chris Wilson Cc: Greg Kroah-Hartman , Peter Zijlstra , Steven Rostedt , LKML , Tvrtko Ursulin , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org Hello, On Fri, Jun 14, 2019 at 04:08:33PM +0100, Chris Wilson wrote: > #ifdef CONFIG_MEMCG > if (slab_state >= FULL && err >= 0 && is_root_cache(s)) { > struct kmem_cache *c; > > mutex_lock(&slab_mutex); > > so it happens to hit the error + FULL case with the additional slabcaches? > > Anyway, according to lockdep, it is dangerous to use the slab_mutex inside > slab_attr_store(). Didn't really look into the code but it looks like slab_mutex is held while trying to remove sysfs files. sysfs file removal flushes on-going accesses, so if a file operation then tries to grab a mutex which is held during removal, it leads to a deadlock. Thanks. -- tejun