Andi Kleen wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] writes:
> > Petr Vandrovec Ing. VTEI wrote:
> >>
> >> Hi,
> >> I have three (five) questions regarding IPX code in 2.3.13. I do not know,
> >> which parts are addressed in upcoming networking patch, but just in case
> >> that they are not...
> >> (1) Should not IPX spinlock around walking through ipx_interfaces
> >> and so on? For example, where ipxitf_find_using_phys (running from
> >> ipx_rcv) locks against removing interface in ipxitf_down (synchronize_bh()
> >> before kfree_s(intrfc,...) should be enough).
> > The kernel lock ensures only one user land process can be in this code
> > at once. The only other source of interference being the timer/net bh
> > code as far as I can see. Putting enable/disable_by_atomic() around the
> > list removal would be enough to fix this. It may not be worth doing
> > that now... the new net patch has a different way of doing things.
> > The new approach would be to have a read/write spinlock for the list.
>
> 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.
>
>
> -Andi
>
Hi,
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,
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
