Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD xen dom0 kernel panic

On Wed, Mar 18, 2009 at 10:32 AM, Christos Zoulas 
<> wrote:
> In article <>, Frank  
> <> 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.

Home | Main Index | Thread Index | Old Index