All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <amwang@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [Patch] workqueue: move lockdep annotations up to	destroy_workqueue()
Date: Thu, 01 Apr 2010 12:28:06 +0800	[thread overview]
Message-ID: <4BB420D6.7050401@redhat.com> (raw)
In-Reply-To: <4BB41DAE.3010605@kernel.org>

Tejun Heo wrote:
> Hello,
> 
> On 04/01/2010 01:09 PM, Cong Wang wrote:
>>> This seems to be from the original thread of frame#3.  It's grabbing
>>> wq lock here but the problem is that the lock will be released
>>> immediately, so bond_dev->name (the wq) can't be held by the time it
>>> reaches frame#3.  How is this dependency chain completed?  Is it
>>> somehow transitive through rtnl_mutex?
>> wq lock is held *after* cpu_add_remove_lock, lockdep also said this,
>> the process is trying to hold wq lock while having cpu_add_remove_lock.
> 
> Yeah yeah, I'm just failing to see how the other direction is
> completed.  ie. where does the kernel try to grab cpu_add_remove_lock
> *after* grabbing wq lock?
> 
>>> Isn't there a circular dependency here?  bonding_exit() calls
>>> destroy_workqueue() under rtnl_mutex but destroy_workqueue() should
>>> flush works which could be trying to grab rtnl_lock.  Or am I
>>> completely misunderstanding locking here?
>> Sure, that is why I sent another patch for bonding. :)
> 
> Ah... great.  :-)
> 
>> After this patch, another lockdep warning appears, it is exactly what
>> you expect.
> 
> Hmmm... can you please try to see whether this circular locking
> warning involving wq->lockdep_map is reproducible w/ the bonding
> locking fixed?  I still can't see where wq -> cpu_add_remove_lock
> dependency is created.
> 

I thought this is obvious.

Here it is:

void destroy_workqueue(struct workqueue_struct *wq)
{
         const struct cpumask *cpu_map = wq_cpu_map(wq);
         int cpu;

         cpu_maps_update_begin();        <----------------- Hold cpu_add_remove_lock here
         spin_lock(&workqueue_lock);
         list_del(&wq->list);
         spin_unlock(&workqueue_lock);

         for_each_cpu(cpu, cpu_map)
                 cleanup_workqueue_thread(per_cpu_ptr(wq->cpu_wq, cpu));  <------ See below
         cpu_maps_update_done();        <----------------- Release cpu_add_remove_lock here

...
static void cleanup_workqueue_thread(struct cpu_workqueue_struct *cwq)
{
         /*
          * Our caller is either destroy_workqueue() or CPU_POST_DEAD,
          * cpu_add_remove_lock protects cwq->thread.
          */
         if (cwq->thread == NULL)
                 return;

         lock_map_acquire(&cwq->wq->lockdep_map); <-------------- Lockdep complains here.
         lock_map_release(&cwq->wq->lockdep_map);
...

Am I missing something??

Thanks.

  reply	other threads:[~2010-04-01  4:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 10:51 [Patch] workqueue: move lockdep annotations up to destroy_workqueue() Amerigo Wang
2010-03-31 11:25 ` Oleg Nesterov
2010-04-01  2:45   ` Cong Wang
2010-04-01  3:56     ` Tejun Heo
2010-04-01  4:09       ` Cong Wang
2010-04-01  4:14         ` Tejun Heo
2010-04-01  4:28           ` Cong Wang [this message]
2010-04-01  4:59             ` Tejun Heo
2010-04-01  5:20               ` Cong Wang
2010-04-01  6:05                 ` Cong Wang
2010-04-01  6:07                   ` Cong Wang
2010-04-01  6:28                   ` Tejun Heo
2010-04-01 16:36     ` Oleg Nesterov
2010-04-02  5:00       ` Cong Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BB420D6.7050401@redhat.com \
    --to=amwang@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.