On Wed, Jan 28, 2009 at 05:41:24PM -0500, John Baldwin wrote: > On Wednesday 28 January 2009 5:04:54 pm Roman Divacky wrote: > > On Wed, Jan 28, 2009 at 03:21:17PM -0500, John Baldwin wrote: > > > On Wednesday 28 January 2009 2:33:18 pm Roman Divacky wrote: > > > > hi > > > > > > > > we dont need Giant to be held for sysctl_ctx_init/SYSCTL_ADD_*, right? > > > > > > Ugh, it looks like the sysctl tree locking is woefully inadequate, so we > > > aren't quite ready for this yet. > > > > what do you mean? should all sysctl_ctx_init/SYSCTL_ADD_* consumers lock > > Giant? I didnt not find a single one (except the scsi stuff) that locks > > it... > > > > can you explain? thnx > > The supposed sysctl lock in kern_sysctl.c is actually worthless. None of the > routines that actually manipulate the sysctl tree to add and remove nodes use > it. Only sysctl itself uses it. It replaces an old 'memlock' hand-rolled > lock from 4.xBSD (in 1.1 of kern_sysctl.c) that I think has to do with > limiting the amount of wired memory, as it looks like sysctl used to always > wire the userland buffers. I've just submitted some changes to p4 to make > the sysctl lock actually protect the sysctl tree that I will test soon. Once > that stuff is done then Giant can be removed here and other places. cool! I found no other places where Giant is used for locking sysctl but please commit at least the patch I posted thnx! romanReceived on Wed Jan 28 2009 - 21:43:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:41 UTC