Re: [Bug 6009] tcpdump causes kernel panic

[Andrew Morton <akpm@osdl.org>]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
>
> On Sat, 2006-02-04 at 15:31 -0800, Andrew Morton wrote:
> > James, I don't recall whether we've fixed this or not?  It was non-trivial,
> > wasn't it?
> 
> It's not fixed, and pretty non-trivial.  Basically we'd have to redo
> most of our generic device (or kobject) handling through workqueues.
> 
> What I'd like for this is a way to tell context.  We know the locking
> context and can cope with that, but it would be nice to tell if we have
> user context or not and then only go through the workqueue for the
> softirq or hardirq contexts.
> 
> If we can get the check, it would probably make sense to do the actual
> manipulation in put_device().
> 

in_interrupt() will return true in hard- or soft-irq context on all
architectures and all .configs - you can certainly use that.

What we cannot use is in_atomic() to detect whether we're inside spinlock -
that only works if CONFIG_PREEMPT.



Regarding this bug, Donny: are you saying that the 3ware failure is caused
by putting the NIC into promiscuous mode (or something related)?  That it
is caused by running tcpdump?