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

[Chris Wilson]

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