Messages in this thread |  | | | Date | Sat, 8 Aug 2009 17:06:04 +0800 | | Subject | Re: [RT] Lockdep warning on boot with 2.6.31-rc5-rt1.1 | | From | Ming Lei <> |
| |
2009/8/8 Alan Stern <stern@rowland.harvard.edu>: > On Fri, 7 Aug 2009, Peter Zijlstra wrote:
>> It used to be that _all_ dev->sem instances were taken on suspend or >> something like that, I think that got fixed a long while back. >> >> I'd have to look at what the current locking requirements for dev->sem >> are. > > It is supposed to be locked whenever the driver core invokes a probe, > remove, or PM-related callback. Under some circumstances, the parent's > semaphore is supposed to be locked as well. Individual subsystems may > have their own requirements in addition to these. > > The ordering requirement is: Don't try to acquire a device's lock if > you already hold the lock for a non-ancestor device. More generally > (if more obscurely): If you already hold device A's lock, then don't > try to acquire the lock for device B unless you already hold the lock > for A & B's most recent common ancestor. >
It seems that the following case is very common, and A and B have no common ancestor, but we can hold device A and B's lock at the same time, can't we?
Thanks.
device A comes in one bus: device_add() ->bus_attach_device() ->device_attach():drivers/base/dd.c /*holding device A's lock*/ ->...drv->probe() /*sleep here some time*/ then device B comes in another bus: device_add() ->bus_attach_device() ->device_attach():drivers/base/dd.c /*holding device B's lock*/ ->...drv->probe() /*sleep here some time*/ -- Lei Ming -- 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/
|  |