On Wed, Aug 11, 1999 at 11:13:12AM +0200, [EMAIL PROTECTED] wrote:
> 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,
At least smp-0806 didn't touch the (missing) locking of IPX and appletalk.
-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]
