DragonFly kernel List (threaded) for 2008-08
DragonFly BSD
DragonFly kernel List (threaded) for 2008-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [netmp] socket accesses

From: Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>
Date: Thu, 21 Aug 2008 23:13:38 +0300

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:

	set by socket layer or on new conn, shouldn't be a problem (recheck)
	see so_options

	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_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



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]