Re: [netmp] socket accesses

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On Thursday 21 August 2008, you wrote:
> 
> :so_error:
> :	The process-side code only ever sets it to 0.
> :	I'm thinking I should add a sequence number, incremented every
> :	time the proto thread sets so_error. That way, the user side
> :	doesn't need to set it to 0 all the time.
>     
>     There is somewhat of an async race here but it doesn't look like
>     the original code really cared about potential races, so I think
>     we can avoid the ref count.  If we really needed we could use
>     the load-and-clear atomic op (I forget exactly what it is).

The seq count should be cheaper than an atomic op though :)

> :so_sigio: set/unset in process context. proto tests so_sigio and then
> :          uses it. This means it can be free()d from under us.
> :	  Easier way is probably to add a new netmsg to set/clear
> :	  ->so_sigio.
> 
>     This works for me.  SIGIO is almost never used so I don't care how
>     inefficient it winds up being.
> 
> :so_oobmark: soreceive, tcp_input (XXX: should be pretty rare. spinlock?)
> 
>     TCP guarantees one OOB mark at a time, so I think this can just
>     be a rbytes/wbytes index and that will deal with the race.

Have to think about it. The main issue here is that the interface for
receiving oob data is *horrible* but, alas, we have to live with that.

> :so_aiojobq: used by aio only, which runs under the mplock anyway
> 
>     Yah.
> 
> :so_upcall{,arg}: XXX accf. netgraph sock, nfs sock should be ok
> :	         gets modified in soisconnected() and withing the upcalls
> :		 which get run by soisconnected() and sowakeup(). So all
> :		 modifications are made in proto thread context and so
> :		 are all accesses. I guess we're safe. accf_data and
> :		 accf_http mess with the sockbuf, but that socket hasn't
> :		 been connected yet, so userspace can't access it. IOW,
> :		 I think running without the BGL is ok here. Not so for
> :		 netgraph and nfs/smb callbacks. Take the BGL there.
>     
>     I think the socket code is safe, but the NFS code might not be
>     with regards to running without the BGL.  That portion of the NFS
>     code could be spin-locked fairly easily.

Well, my intention was to take the BGL in the nfs/smb and netgraph upcalls
for now.

Thanks,
Aggelos