Re: lockdep: strange %s#5 lock name

2014-02-13 Thread Tejun Heo
On Thu, Feb 13, 2014 at 10:32:53PM +0100, Peter Zijlstra wrote: > On Thu, Feb 13, 2014 at 04:26:45PM -0500, Tejun Heo wrote: > > > It seems to me that when the second time alloc_workqueue() is called > > > from the same code path, it would have two locks with the same key, but > > > not the same &w

Re: lockdep: strange %s#5 lock name

2014-02-13 Thread Peter Zijlstra
On Thu, Feb 13, 2014 at 04:26:45PM -0500, Tejun Heo wrote: > > It seems to me that when the second time alloc_workqueue() is called > > from the same code path, it would have two locks with the same key, but > > not the same &wq->name, which doesn't meet lockdep's assumption. > > Dang... I revert

Re: lockdep: strange %s#5 lock name

2014-02-13 Thread Tejun Heo
On Thu, Feb 13, 2014 at 12:35:24PM +0800, Li Zhong wrote: > [5.251993] [ cut here ] > [5.252019] WARNING: CPU: 0 PID: 221 at kernel/locking/lockdep.c:710 > __lock_acquire+0x1761/0x1f60() > [5.252019] Modules linked in: e1000 > [5.252019] CPU: 0 PID: 221 Comm

Re: lockdep: strange %s#5 lock name

2014-02-12 Thread Li Zhong
On Tue, 2014-02-11 at 10:27 -0500, Tejun Heo wrote: > On Tue, Feb 11, 2014 at 12:00:36PM +0100, Peter Zijlstra wrote: > > > Looks good to me. Can you please post the patch with SOB? > > > > --- > > Subject: workqueue: Fix workqueue lockdep name > > > > Tommi noticed a 'funny' lock class name: "%

Re: lockdep: strange %s#5 lock name

2014-02-11 Thread Tejun Heo
On Tue, Feb 11, 2014 at 12:00:36PM +0100, Peter Zijlstra wrote: > > Looks good to me. Can you please post the patch with SOB? > > --- > Subject: workqueue: Fix workqueue lockdep name > > Tommi noticed a 'funny' lock class name: "%s#5" from a lock acquired in > process_one_work(). It turns out th

Re: lockdep: strange %s#5 lock name

2014-02-11 Thread Peter Zijlstra
> Looks good to me. Can you please post the patch with SOB? --- Subject: workqueue: Fix workqueue lockdep name Tommi noticed a 'funny' lock class name: "%s#5" from a lock acquired in process_one_work(). It turns out that commit b196be89cdc14 forgot to change the lockdep_init_map() when it change

Re: lockdep: strange %s#5 lock name

2014-02-10 Thread Tejun Heo
On Mon, Feb 10, 2014 at 08:28:46PM +0100, Peter Zijlstra wrote: > Lol.. its correct afaict: > > struct workqueue_struct *__alloc_workqueue_key(const char *fmt, > unsigned int flags, > int max_active, >

Re: lockdep: strange %s#5 lock name

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 09:19:43PM +0200, Tommi Rantala wrote: > Hello, > > Noticed a suspicious "%s#5" lock name in a lockdep splat while fuzzing > with trinity. > > [249844.531638] #0: (%s#5){.+.+.+}, at: [] > process_one_work+0x240/0x690 Lol.. its correct afaict: struct workqueue_struct *_

lockdep: strange %s#5 lock name

2014-02-10 Thread Tommi Rantala
Hello, Noticed a suspicious "%s#5" lock name in a lockdep splat while fuzzing with trinity. Tommi [249844.491141] INFO: task kworker/u2:2:32113 blocked for more than 120 seconds. [249844.493268] Not tainted v3.13-11268-g8a1f006 #3 [249844.494731] "echo 0 > /proc/sys/kernel/hung_task_timeou