login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2010
»
April
»
1
Re: [Patch] workqueue: move lockdep annotations up to destroy_workqueue()
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Cong Wang
Subject:
Re: [Patch] workqueue: move lockdep annotations up to destroy_workqueue()
Date: Wednesday, March 31, 2010 - 11:07 pm
Cong Wang wrote:
quoted text
> Cong Wang wrote: >> Tejun Heo wrote: >>> Hello, >>> >>> On 04/01/2010 01:28 PM, Cong Wang wrote: >>>>> 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); >>>> ... >>> >>> Yeap, the above is cpu_add_remove_lock -> wq->lockdep_map dependency. >>> I can see that but I'm failing to see where the dependency the other >>> direction is created. >>> >> >> Hmm, it looks like I misunderstand lock_map_acquire()? From the >> changelog, >> I thought it was added to complain its caller is holding a lock when >> invoking >> it, thus cpu_add_remove_lock is not an exception. >> > > Oh, I see, wq->lockdep_map is acquired again in run_workqueue(), so I > was wrong. :) > I think you and Oleg are right, the lockdep warning is not irrelevant. >
Oops, typo, I meant "is irrelevant." ;) --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
[Patch] workqueue: move lockdep annotations up to destroy_ ...
, Amerigo Wang
, (Wed Mar 31, 3:51 am)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Oleg Nesterov
, (Wed Mar 31, 4:25 am)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 7:45 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Tejun Heo
, (Wed Mar 31, 8:56 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 9:09 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Tejun Heo
, (Wed Mar 31, 9:14 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 9:28 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Tejun Heo
, (Wed Mar 31, 9:59 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 10:20 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 11:05 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Wed Mar 31, 11:07 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Tejun Heo
, (Wed Mar 31, 11:28 pm)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Oleg Nesterov
, (Thu Apr 1, 9:36 am)
Re: [Patch] workqueue: move lockdep annotations up to dest ...
, Cong Wang
, (Thu Apr 1, 10:00 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
David Howells
[PATCH] KEYS: Use the variable 'key' in keyctl_describe_key()
Dave Jones
Re: OT: character encodings (was: Linux 2.6.20-rc4)
Greg Kroah-Hartman
[PATCH 17/36] sysdev: detect multiple driver registrations
Sam Ravnborg
Re: [PATCH] kbuild: fix make V=1
Nick Piggin
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
git
:
Stephen R. van den Berg
Re: [RFC] origin link for cherry-pick and revert
Junio C Hamano
Re: [PATCH 1/2] Teach git-describe to display distances from tags.
Johannes Schindelin
Re: [PATCH 2/2] git-svn: support fetch with autocrlf on
Junio C Hamano
Re: [PATCH 6/6] Teach core object handling functions about gitlinks
Michael S. Tsirkin
git-kill: rewrite history removing a commit
linux-netdev
:
Jarek Poplawski
Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event...
Lennert Buytenhek
Re: Distributed Switch Architecture(DSA)
Daniel Schaffrath
Re: tcp bw in 2.6
Matt Mackall
Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference
Guo-Fu Tseng
Re: jme: UDP checksum error, and lots of them
openbsd-misc
:
Claudio Jeker
Re: Vlan Tag on Vlan Tag (l2tunneling)
Josh Grosse
ssh/sshd challenge-response seems to have stopped working in -current
Pieter Verberne
File collision while using pkg_add
Tomas Bodzar
bsd: uvm_mapent_alloc: out of static map entries
Community First Financial
Teacher A+ Loan
git-commits-head
:
Linux Kernel Mailing List
ath9k: Added get_survey callback in order to get channel noise
Linux Kernel Mailing List
tracing: protect reader of cmdline output
Linux Kernel Mailing List
kconfig: recalc symbol value before showing search results
Linux Kernel Mailing List
KVM: VMX: Clear CR4.VMXE in hardware_disable
Linux Kernel Mailing List
USB: set correct configuration in probe of ti_usb_3410_5052
Colocation donated by:
Syndicate