sysctl locking

Suleiman Souhlal ssouhlal at FreeBSD.org
Fri Dec 17 00:19:20 PST 2004


Hello,

On Dec 13, 2004, at 6:32 AM, Max Laier wrote:

> 1) Extend sysctl_add_oid() to accept an additional mutex argument.
> 2) Extend the simple sysctl handler to use this mutex to protect the 
> actual
>    write(?read?). We must not hold the mutex during the useland copy 
> in/out so
>    we must move to temporary storage.
> 3) To maintain the current API and behavior we use &Giant as the 
> default
>    fallback argument. This might need some extension for complex 
> handler (i.e.
>    no mutex given -> acquire Giant before calling the complex handler).
>
> What do people think of this? Does it make any sense? Should we be 
> concerned
> at all? Does the extension make sense? Comments?

I have implemented this. The diff is at 
http://people.freebsd.org/~ssouhlal/sysctl-sx-locking-20041214.diff
It also needs the patch at 
http://people.freebsd.org/~ssouhlal/sx_xlocked.diff which introduces a 
sx_xlocked() function.

Unfortunately, we still need to look at every single SYSCTL_PROC, and 
make either grab Giant, lock correctly, or make sure it doesn't need 
any locking. :(

--
Suleiman Souhlal     | ssouhlal at vt.edu
The FreeBSD Project  | ssouhlal at FreeBSD.org

_______________________________________________
freebsd-current at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


More information about the freebsd-arch mailing list