lkml.org 
[lkml]   [2004]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] USB: fix Scheduling while atomic warning when resuming.
Date
On Tuesday 21 December 2004 9:27 pm, Jeff Garzik wrote:
> > There's no guarantee that suspend() and resume() methods
> > are only called during system-wide suspend and resume.
>
> That is precisely the reason why I am concerned. If it was only during
> system-wide resume, the impact of the very-long mdelay() would be more
> difficult to notice.
>
> You also ignored my question :)

I didn't ignore it; I answered it with a question! If you had
answered mine, you'd have had the answer to yours ... :)

One way another task can be active during resume is with sysfs:
"echo -n 0 > /sys/devices/.../power/state", after similar selective
suspend of the device. That's uncommon for now, primarily useful
for unit-testing driver suspend/resume. Plus, its design is
currently borked; the pm core code doesn't bother to suspend
children of the device first. But I do expect that selective
suspend/resume should work in Linux; it's not reasonable to design
the pm framework otherwise.

But in any case, while it'd be difficult to notice that mdelay()
in current systems (since selective suspend/resume is still rare)
it'd clearly be wrong to assume that resume() methods don't need
to have mutual exclusion during their critical sections.


> If the PCI layer is calling the resume method for a PCI device while
> simultaneously calling the suspend method, that's a PCI layer problem.

I never suggested such a scenario. Though that would be another
case where such critical sections matter, like the remove() method.


> Similarly, If the USB layer is calling into your driver while you are
> resuming, something is broken and it ain't your locking.

Which gets back to the question I asked you: if not the lock in
question, what's ensuring that everything behaves right?

As I said originally, I don't much like long udelays, but
at least it's clearly correct in terms of mutual exclusion.
You've not shown any solution that's equivalently correct.

- Dave
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.074 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site