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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
