The socket code is designed to be mostly multithreaded on a uniprocessor. Since
day 1 its been the case that two processes can share a socket and one might
page fault while copying sk_buff data. If we are going to thread this
further then for most protocols we are looking at the same routines for
a lot of the work. Ultimately (probably post 2.2) most of the protocol
processing will be in the user context and a couple of kernel threads.
> We already have a lock for every socket: the inode semaphore. Could you
> use this to protect the socket state transitions? Possibly this will be
Is the inode semaphore interrupt safe ?
Alan