Re: scheduler support to lock user processes out?

["M. Warner Losh" <imp%bsdimp.com@localhost>]

In message: <200802211210.NAA0000220880%zel459.zel.kfa-juelich.de@localhost>
            Matthias Drochner <M.Drochner%fz-juelich.de@localhost> writes:
: 
: imp%bsdimp.com@localhost said:
: > : -FreeBSD acquires the big kernel lock before suspending
: > :  devices, holding it all the time until after resume.
: > For the record, this doesn't work well and is done only because the
: > device tree's data structures are protected by Giant. 
: 
: You mean, it doesn't work well because it is not a 100%
: protection against other code interfering with the
: suspend process, or does it have bad side effects?

I'm saying that it is insufficient.  The Giant lock doesn't lock out
much of the kernel these days.  Along with fine grain locking comes
the need to have fine grained control over interrupt processing,
thread scheduling, etc.

: In my experience, while NetBSD doesn't protect the
: device tree either, this was less a problem. I often
: got "fp save ipi didn't" panics w/o the biglock, which
: might eg. be caused by a CPU reading nonsense from a
: suspended device, causing it to spin in a loop.
: With the biglock, suspending works perfectly well
: on my dual-core.
: (I'm not questioning that correct locking everywhere
: would be preferrable.)

Correct.  FreeBSD's giant won't solve this problem, nor will NetBSD's
biglock when it covers less of the kernel.  The real problem is
touching a suspended device, and locking isn't going to fix that.  The
other real problem quickly becomes devices or threads scheduling new
work after a device is suspended and/or the need for devices to do
stuff during the suspend that depend on other parts of the system that
may have already been (bogusly) suspended.

Warner