Re: NetBSD xen dom0 kernel panic

[Peter <necedemalis%gmail.com@localhost>]

On Wed, Mar 18, 2009 at 11:34 PM, Thor Lancelot Simon 
<tls%rek.tjls.com@localhost> wrote:
> On Wed, Mar 18, 2009 at 09:24:26PM -0400, peter wrote:
>> On Wed, 2009-03-18 at 18:59 -0400, Thor Lancelot Simon wrote:
>> > On Wed, Mar 18, 2009 at 03:20:11PM -0400, Peter wrote:
>> > >
>> > > In what way is using pool_foo safe in an interrupt context?
>> >
>> > In the way the manual page says: if the pool is initialized with the
>> > highest IPL in effect in any interrupt context in which it will be 
>> > accessed,
>> > and all accesses to the pool are protected against interrupts at that IPL
>> > or lower.
>>
>> And the malloc and free calls aren't an issue?
>
> Uh, what malloc and free calls, the ones that pool(9) doesn't make?
>
> There is one call to malloc in subr_pool.c, to allocate a tracing
> structure if POOL_DIAGNOSTIC is defined -- and that's in pool_init(),
> which only a madman would call from interrupt context.
>
> The manual page says what you have to do to use pool(9) safely
> from interrupt context.  Obey it and the code will work fine.
>
> Thor
>
I am not certain of this, but I think the bridge code calls
bridge_rtupdate from interrupt contexts and I know I suggested in an
earlier email that calls to this be put on a soft interrupt queue.
bridge_rtupdate calls pool_get which calls rumpuser_malloc which, I'm
guessing here, is a malloc call.

This may in fact be interrupt safe, but as for believing everything
the manual page says... well the code does not work fine, likely
that's the bridge's problem, but it still needs to be fixed.

Does anyone know if that might be a solution to the lock errors?
Putting rtupdate on a soft interrupt queue?  Manuel Bouyer suggested
that upper protocols do something similar in general, though, so
perhaps its not just rtupdate or perhaps I'm wrong and its not
rtupdate at all.

Peter