Re: brlock_is_locked()?

[Brad Chapman <kakadu_croc@yahoo.com>]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

--- "David S. Miller" <davem@redhat.com> wrote:
>    From: Brad Chapman <kakadu_croc@yahoo.com>
>    Date: Wed, 22 Aug 2001 11:33:12 -0700 (PDT)
>    
>    	It almost isn't. The problem starts when a third-party protocol
>    module grabs BR_NETPROTO_LOCK, unloads itself from the networking stack,
>    and then tries to call ip6_conntrack_protocol_unregister(). Deadlock.
>    The problem is that we need TWO locks: the brlock to seal the network
> stack,
>    and the conntrack rwlock to delete the protocol struct. Sure, you can
>    always share the rwlock and leave it at that, but if all you need it for
>    is to load/unload your protocol functions, then why bother polluting
>    the symbol tables?
>    	What do you think? Share the rwlock and make everybody who has
>    the brlock just use the core function?
> 
> You are only showing me that there is potential a deficiency in the
> netfilter interfaces.  You ought to discuss with the netfilter people
> a way to make the interfaces work better.
> 
> This is exactly what I said needed to be done.
> 
> Later,
> David S. Miller
> davem@redhat.com

Mr. Miller,

	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. It doesn't necessarily _have_ to be done, 
because all the points which might make use of the protocol handlers are 
already locked or could be changed to use the lock, but if it should
be done, then you need a way to find out if the brlock is locked,
so that you can be fair to other people (I checked the brlock code and
didn't find any schedule()s; there's probably a reason for that).
	I suppose that if it really can't be done, then I'll remove the lock commands
for BR_NETPROTO_LOCK in the protocol API and just wait until people
report Evil Things(tm) happening when they unload. Besides, any netfilter
interface changes will have to wait until 2.5.

Brad   


=====
Brad Chapman

Permanent e-mail: kakadu_croc@yahoo.com
Current e-mail: kakadu@adelphia.net

Reply to the address I used in the message to you,
please!

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/