Date: Wed, 30 Oct 2002 20:40:18 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: Gregory Bond <gnb@itga.com.au> Cc: Andriy Gapon <avg@icyb.net.ua>, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/44417: ipfw layer2 rules are not checked for ether_output_frame() on bridged interface Message-ID: <200210310140.g9V1eIK7062289@khavrinen.lcs.mit.edu> In-Reply-To: <200210310046.LAA06800@lightning.itga.com.au> References: <200210310046.LAA06800@lightning.itga.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 31 Oct 2002 11:46:04 +1100, Gregory Bond <gnb@itga.com.au> said: > In the old days, on the early PDP-11 Unix versions, this was done with > hardware interrupt masks, and the various splXXX() levels had a strict > hierarchy, so spltty() meant "don't enable tty interrupts, but let net and > bio interrupts happen", but splbio() meant "Don't enable any interrupts at > all." Actually, in the old days (lasting right through the VAX era), they were numbers. IIRC, what was more recently called splbio() was previously spl6(). SPL ::= ``Set (Interrupt) Priority Level''. > Note that there are no actual semaphores/spinlocks here, it's all done either > with hardware interrupt masks or simple queues. Actually, there are no queues involved. An interrupt which arrives while masked sets a pending bit (in the variable `ipending') which splx() will call once it is unmasked. > Of course, in an SMP system, this all gets much harder. I dunno how the > FreeBSD 5 kernel handles SPLs. It doesn't. The spl*() functions are still there, but no-ops, to remind developers working on adding fine-grained locking to the system where the critical sections used to be. Since most of the kernel still runs under a single lock (called ``Giant''), there is effectively less concurrency than there was under 4.x, where at least a bio handler could still run when network hardware was masked (splimp()). This situation will improve over time, as more of the critical subsystems are updated to use the new locking primitives. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210310140.g9V1eIK7062289>