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