Re: NetBSD xen dom0 kernel panic

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

On Wed, Mar 18, 2009 at 10:32 AM, Christos Zoulas 
<christos%astron.com@localhost> wrote:
> In article <49C0957E.5050304%searchy.net@localhost>, Frank  
> <netbsd%searchy.net@localhost> wrote:
>>YAMAMOTO Takashi wrote:
>>>> Good, I think that the that pools that are used in interrupt contexts,
>>>> should be using pool_cache_<foo> not pool_<foo> like the signal does.
>>>> Is that right? Can you try to make this change?
>>>>
>>>> christos
>>>
>>> it's fine to use pool_foo in interrupt context, if the pool is set up
>>> properly.  however, this particular pool is not expected to be used
>>> in interrupt context.  it's possible to make packet filters interrupt-safe,
>>> but imo it's better to fix bridge_ipf.
>>>
>>> YAMAMOTO Takashi
>>
>>A temporary solution would be to disable BRIDGE_IPF ?
>
> that will work.
>
>>If any patches become available, let me know so I can test them.
>
> Yamt,
>
> Can you explain how to fix bridge_ipf? Processing the packets in a separate
> thread does not really work - I think - because you need to say yes or no,
> immediately.
>
> christos
>
>

In what way is using pool_foo safe in an interrupt context?  I am
unfamiliar with this but also have these lock errors on an alpha
current build using bridge_ipf.  From what I can tell, bridge_ipf
should be modified to use some kind of static cache for storing
routing entrys, or rtupdate calls should be placed on some soft
interrupt queue.

Is this correct?  I can try my hand at fixing it but before I start
I'd like to know that I'm not way off base and that I wouldn't be
duplicating the ongoing efforts of someone more familiar with this.