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
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
