Steve Bellovin wrote:
> 
> Hmm -- this is the same problem with have with USB umass devices.  It 
> would be good to find a more general solution.

I hadn't been following that thread; is it in fact the same issue where
a USB device is connected after boot, detected, and attach fails to get
contiguous memory?

If so, it seems there's a general problem that deserves a general solution.
The *most* general approach would seem to be to say, look, if the kernel
needs some contiguous space and there are some user pages in the way, they
need to be kicked out.  If they're dirty we need to be able to wait while
they're kicked out, and if all of the hot-pluggable types of buses are
watched by dedicated kernel threads, then presumably attach is running in
a thread that can be blocked while that happens.  That does not require any
pre-reservation of space, at the cost that the attach may be delayed for a
moment while some pages get flushed.  (Assuming there aren't some more
complex dependencies I don't know about that could lead to deadlock while
flushing the pages.)

If the solution can be slightly less general in the sense of wanting a
pre-reservation of expected contiguous space demands, then there's the
approach of using the reserved space only for readonly pages until needed,
and then kicking the pages out doesn't require any flushing and could
probably be done without switching thread context.

Either mechanism on its own could probably be called a solution; if both
were available you could accept reservations for snappy attaches but also
be forgiving if the reservation was underestimated.

disclaimer: I'm pretty new to NetBSD and making a bunch of assumptions here
concerning kernel code I haven't much looked at....

-Chap