On Wed, Aug 11, 1999 at 01:58:05PM +0200, Petr Vandrovec Ing. VTEI wrote:
> On 11 Aug 99 at 11:52, Andi Kleen wrote:
> > > > In theory. From short inspection it seems that whoever removed the kernel
> > > > lock from send/recvmsg forgot to add it again in IPX/AppleTalk/...
> > > > So either the kernel lock needs to be added for these protocols again,
> > > > or someone who knows IPX,Appletalk etc. needs to do the work of properly
> > > > spinlocking them.
> > > The new net patch does this. In case anyone's looking for it and missed it
> > > appearing, look on ftp.inr.ac.ru or a mirror for the smp-* patches in the
> > > ip-routing directory. The current one was smp-0810 last time I looked,
> > At least smp-0806 didn't touch the (missing) locking of IPX and appletalk.
Seems I was wrong. 0810 has SOCKOPS_WRAP, which adds lock_kernel. My fault,
the idea that Alexey could forget such a trivial bit shouldn't have occurred
to me ...
But lock_kernel is bad and slow, so private locking is better. The cli/sti
in ipx is also very slow and not nice to the system.
> smp-0810 does not too, except removing firewall code :-( Is there some
It is replaced with netfilter. Netfilter is the old firewalling on stereoids,
so be happy ..
> document, which networking functions are safe to call with which locks
> held/unheld (dev_queue_xmit, in which context registered receiver function
> (ipx_rcv) is invoked...) or is IPv4 best source?
dev_queue_xmit should be safe to be called without any locks.
skb_datagram_* should be safe too (although it may need the smp-* patches
for some corner cases)
*_user stuff can run without locks (and must be run outside any spinlocks
because they can sleep)
The caller should ensure that the sk doesn't go away
In summary just do your private locking and let the other subsystems worry
about their locks at their own.
-Andi
--
This is like TV. I don't like TV.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
