James Bottomley <James.Bottomley@xxxxxxxxxxxx> 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? - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
