Date: Sun, 5 Oct 2003 14:44:50 +0100 From: Bruce M Simpson <bms@spc.org> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <20031005134450.GC13164@saboteur.dek.spc.org> In-Reply-To: <200310051226.h95CQJN1049247@gw.catspoiler.org> References: <200310050937.h959bldI091908@repoman.freebsd.org> <200310051226.h95CQJN1049247@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 05, 2003 at 05:26:19AM -0700, Don Lewis wrote: > In the SMP case the data can change even without pre-emption. There > have been a number of discussions (arch@, smp@, arch-handbook, etc.) > about adding a mutex parameter to the sysctl API. Someone even > submitted a PR with a patch a few months ago (kern/54439), which I had > hoped to review but never found the time to. My GENERIC kernel with vslock() et al. reintroduced, and the pre-emption check in sysctl_handle_opaque(), appears to be OK. I am confident the security issue has now been addressed in -CURRENT (it was limited to sysctl_handle_opaque()), but we now have the larger problem of how to deal with procedural sysctl() handlers in the wider kernel. I can see Peter has encouraged me to open a huge can of worms. Let's continue discussion about what to do on -arch. This has been a learning experience... BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031005134450.GC13164>