On Tue, Jan 13, 2015 at 12:41 AM, Thomas Graf <tg...@suug.ch> wrote: > On 01/13/15 at 03:50pm, Ying Xue wrote: >> On 01/12/2015 08:42 PM, Thomas Graf wrote: >> > On 01/12/15 at 09:38am, Ying Xue wrote: >> >> Hi Thomas, >> >> >> >> I am really unable to see where is wrong leading to below warning >> >> complaints. Can you please help me check it? >> > >> > Not sure yet. It's not your patch that introduced the issue though. >> > It merely exposed the affected code path. >> > >> > Just wondering, did you test with CONFIG_DEBUG_MUTEXES enabled? >> > >> > >> >> After I enable above option, I don't find similar complaints during my >> testing. > > I can't reproduce it in my KVM box either so far. It looks like a > mutex_lock() on an uninitialized mutex or use after free but I can't > find such a code path so far.
Couldn't that be the delayed work is still running after rhashtable is destroyed by its caller? I mean, cancel_delayed_work_sync() should be called in rhashtable_destroy()? Of course, it may be caller's responsibility to ensure that, I haven't looked into it that much. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
