Locking netatm

[Bruce Evans]

On Mon, 29 May 2006, Kris Kennaway wrote:

> On Mon, May 29, 2006 at 01:52:48PM +0900, gnn at 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