Messages in this thread | | | Date | Wed, 22 Aug 2001 12:00:51 -0700 (PDT) | Subject | Re: brlock_is_locked()? | From | "David S. Miller" <> |
| |
From: Brad Chapman <kakadu_croc@yahoo.com> Date: Wed, 22 Aug 2001 11:53:51 -0700 (PDT)
It's not really a deficiency. Rusty apparently decided that in order to be SMP-compliant and to prevent Oopses, that the unregistration function should grab the brlock so that all the packets would pass through the protocol-handling functions.
So arrange you code such that you aren't holding the netproto lock when you call the unregistration function.
It is possible to shut down all references to whatever you are unregistering, safely drop the lock, then call the netfilter unregister routine.
(I checked the brlock code and didn't find any schedule()s; there's probably a reason for that).
Ummm, this is SMP 101, you can't sleep with a lock held. The global kernel lock is special in this regard, but all other SMP locking primitives may not sleep.
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |