linux-kernel - Re: [BUG] lockdep splat with kernfs lockdep annotations and slab mutex from drm patch??

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <156052491337.7796.17642747687124632554@skylake-alporthouse-com>
Date:   Fri, 14 Jun 2019 16:08:33 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>, Tejun Heo <tj@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Tvrtko Ursulin <tvrtko.ursulin@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [BUG] lockdep splat with kernfs lockdep annotations and slab mutex from
 drm patch??

Quoting Steven Rostedt (2019-06-14 14:39:14)
> I'm trying to debug some code where I need KASAN and lockdep enabled
> but I can't get past this splat unrelated to my code. I bisected it
> down to this commit:
> 
>  32eb6bcfdda9da ("drm/i915: Make request allocation caches global")
> 
> To make sure it wasn't a bad bisect, I removed the patch and the splat
> goes away. I add the patch back, and the splat returns. I did this
> several times, so I have a large confidence that this is the cause of
> the splat, or at least it is the commit that triggers whatever is going
> on.
> 
> Perhaps all the cache updates caused the slab_mutex to be called
> inverse of the kernfs locking?
> 
> Attached is my config.
> 
> Also might be helpful, the splat happens:
> 
>   kernfs_fop_write()
>     ops->write == sysfs_kf_write
>        sysfs_kf_write()
>          ops->store = slab_attr_store

More interestingly,

static ssize_t slab_attr_store(struct kobject *kobj,
                                struct attribute *attr,
                                const char *buf, size_t len)
{
        struct slab_attribute *attribute;
        struct kmem_cache *s;
        int err;

        attribute = to_slab_attr(attr);
        s = to_slab(kobj);

        if (!attribute->store)
                return -EIO;

        err = attribute->store(s, buf, len);
#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().
-Chris