Alan Stern wrote:
On Tue, 21 Sep 2004, David Brownell wrote:
As one example, consider the problem you've been having with deadlocks
involving dpm_sem. That entire design is misconceived. It forces dpm_sem
to be a single chokepoint for the whole driver model.
Right. The deadlocks are because the PM lists are protected using
that semaphore, rather than a spinlock, and because the pmcore code
uses the semaphore for too many other things. The (bogus) assumption
is that those other things never involve changing those lists (like
by adding/removing devices). Ergo self-deadlock.
Or put it another way: if the semaphore was used for _everything_, and not
just by the PM core but by drivers as well so that the entire driver model
was completely serialized, then again there wouldn't be any deadlock.
I don't see how that would solve anything. Unless you mean to
suggest that everything could always assume the lock was held,
in which case it wouldn't protect against anything ... :)
The root cause of the self-deadlocks is that the driver model
code has to be re-entrant, so that logic in suspend/resume
paths can do things that can be done at other times too. That
means the locking mustn't be context-dependent, and the lock
scope must shrink to something sane (like, not held during
potentially long-lasting outcalls).
I'll disagree about dpm_sem; uniformity isn't the problem, it's lock scope.
Per-device locking of some kind is certainly needed to handle device power
management (lest tasks interfere on a given device).
Ah, but if _all_ those tasks, in addition to power management, used
dpm_sem then there wouldn't be any interference. Just blockage and
slowdowns. (Not that I'm advocating this -- per-device locking like in
USB is the best way to go.)
Again, I don't see how the re-entrancy issues would be addressed.
By the way, the PM lists aren't necessary. By using the existing list
pointers in the device structure it's possible to do a proper tree
traversal with bounded stack usage. I don't know if anyone's interested
in that...
I've had the same thought about bounded memory, but I don't think
they'd work well without separate PM lists. At least without
adding rude "whole system is serialized" constraints ...
I do want to add PMcore primitives to walk a (sub)tree in constant
stak space, so that USB can rely on that to ensure subtrees (as for
example USB hub to USB-storage to SCSI-Host to SCSI-Disk) can work
even when they jump out of the USB domain.
(And today I came up with a way to do suspend/resume without using
locktree and without using multiple passes for locking. I can describe it
later if you care to hear about it.)
Not right now. Let's get the root hub PM integration to behave first.
That subtree-traversal logic can have some of the same effects, fwiw.
In the end, it may turn out to be necessary for the entire driver model to
adopt the form of locking that usbcore now uses, or something very similar
to it.
Wouldn't surprise me at all. But getting there by incremental improvements
isn't going to be straightforward. And locking is subsidiary to having a
usable/correct model.
I can't argue with that. The only name in the drivers/base/power/* files
in Patrick Mochel; is anybody else working on solving these issues? (Is
he, for that matter?)
Various folk, not all working together. I mentioned the swsusp/pmdisk
merge (in the MM tree), that's what Patrick is on lately, but I don't
know how much time he has for anything else (like pmcore fixes). The
folk working on embedded Linuxes obviously care. But most of the
energy (still) seems to go to making laptop suspend/resume work.
- Dave
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
