[netmp] socket accesses
Aggelos Economopoulos
aoiko at cc.ece.ntua.gr
Thu Aug 21 13:17:48 PDT 2008
On Friday 08 August 2008, Aggelos Economopoulos wrote:
[...]
> Assuming we can move all list modification in protocol thread context, the
> list traversal would still be tricky. Maybe a spinlock protecting the lists and
> queue lengths is in order for now? The same lock could be reused for protecting
> SS_INCOMP, SS_COMP. In the future we might try something more clever if this
> becomes a performance issue. Opinions?
>
> The other so_* fields seem to be easier; I'll send a separate mail for those.
Pasting from my notes:
so_options:
set by socket layer or on new conn, shouldn't be a problem (recheck)
so_pcb:
see so_options
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.
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.
so_oobmark: soreceive, tcp_input (XXX: should be pretty rare. spinlock?)
so_aiojobq: used by aio only, which runs under the mplock anyway
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.
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
More information about the Kernel
mailing list