Mr. Miller, --- "David S. Miller" wrote: > From: Brad Chapman > 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 understand that. What I'm afraid of is someone who writes a third-party protocol module for ip_conntrack (or ip6_conntrack) and tries to call the wrapper with BR_NETPROTO_LOCK held. LISB, IMHO the primary difficulty is not protecting the protocol linked-list from packets inside the conntrack; it's protecting the protocol linked-list from packets in the netfilter stack. FWICT, it should be almost impossible for packets to move around in conntrack with the rwlock but not the brlock; but strange things can happen...... > > (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. Grrr....I read Rusty's Unreliable Guide to Kernel Locking (twice) and still didn't remember that. Guess you have to schedule() yourself. > > Later, > David S. Miller > davem@redhat.com 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/