[netmp] socket accesses
Matthew Dillon
dillon at apollo.backplane.com
Thu Aug 21 13:43:30 PDT 2008
: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).
: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.
: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.
:so_emuldata: only touched by linux connect, which runs under the mplock
:so_accf: only modified by sockopt code. just change do_setopt_accept_filter()
: to first clear the SO_ACCEPTFILTER flag and *then* clear so_accf.
: (it's already careful to only set the flag after initializing so_accf)
: XXX: mem barriers
:
:Opinions?
:
:TIA,
:Aggelos
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the Kernel
mailing list