Date: Mon, 29 May 2006 22:02:38 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Kris Kennaway <kris@obsecurity.org> Cc: Robert Watson <rwatson@freebsd.org>, gnn@freebsd.org, freebsd-atm@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Locking netatm Message-ID: <20060529213903.G24267@delplex.bde.org> In-Reply-To: <20060529051811.GA60877@xor.obsecurity.org> References: <20060528230058.GA836@lucy.pool-70-17-33-65.pskn.east.verizon.net> <m23betzb33.wl%gnn@neville-neil.com> <20060529051811.GA60877@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 May 2006, Kris Kennaway wrote: > On Mon, May 29, 2006 at 01:52:48PM +0900, gnn@FreeBSD.org wrote: >>> So my question is, were network interrupts disabled when mucking >>> with the atm_timeq list because a generated interrupt can modify >>> structures within the list? This use is probably very >>> netatm-specific. I'm still studying the timeout code to understand >>> what it's doing. >> >> The spl() calls haven't disabled real interrupts, as far as I know, >> for quite a while. They acted as general code locks to prevent >> simultaneous access to data structures while an update was in >> progress. In terms of the timeq, the locks were acting as a mutex now >> would to protect the list during an update. > > Actually the spl calls have all been NOPs since the early 5.0 days, > and they were just left in an mnemonic placeholders showing which > code/data sections need to be protected. Actually the spl calls were sort of replaced by Giant locking. The Giant locking is just implicit and magic where the non-null spl "locking" was explicit and less magic. The effect was initially similar to replacing all spl calls by a non-null splhigh() (giving very coarse-grained locking to interrupt handlers) and also adding splhigh() to all kernel entry points (giving even coarser-grained locking). Now many things are not under Giant, the Giant-locked things are not locked out so much by other things, but they still lock out each other and still depend very much on the Giant locking having much the same effect as splhigh(). To the extent that subsystems called by netatm are MPSAFE, you can just remove the spl "locking". It hasn't done anything for a long time, and the Giant locking is also null for other MPSAFE subsystems. However, the other subsystems might not be fully MPSAFE yet. Some have to be run in !MPSAFE mode because their callers are not MPSAFE, and this might hide bugs. Locking for timing probably isn't very important. Giant and other locking can give very large latency in hard-to-predict ways, but some things have been running for a long time without this causing many obvious problems other than reduced efficiency. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060529213903.G24267>