Re: What's an "MPSAFE" driver need to do?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> What's kernel_lock?  man -k turns up nothing; some grepping leads me
>> to think it's what I've seen called on the lists a `giantlock',
>> which is what I thought all this new locking stuff was supposed to
>> be getting away from.
> Yes, there is a giant lock.  Some parts of the kernel need to have
> that lock to work correctly.  [...]

So the giantlock still exists because it's in a process of transition
right now?  Got it...I think.

> Arguably each driver should havea comment, but the lack of MPSAFE in
> flags (and an easy-to-overlook 0 instead!) is how you can tell; that
> means that drivers written for the good old days of a (single) PDP-11
> cpu still work safely.

Okay.  I don't think I can rely on that, though, because the things I'm
porting that have led me to care about locking are not just device
drivers.  One of them is a new socket address family (AF_TIMER -
basically, a file descriptor attached to a setitimer-style timer) and
the other, while it has a device driver interface, is also called into
from various places in the disk drivers, disk drivers which may or may
not be MPSAFE themselves.

I have them working; I'll use them for a while and see if I have any
reason to think I've gotten the locking wrong.  Perhaps fortunately,
most of my 5.2 machines are multiprocessor, so locking mistakes
probably will get noticed eventually - especially since I was generous
with my KASSERT()s, and have DIAGNOSTIC and DEBUG turned on.

> It's a fair point about memory barriers and mutexes; I had never
> thought of that.

It _is_ easy to miss.  Locking is full of subtle cases, and so is
memory caching and reordering; put the two together and it's a wonder
any of this stuff works at all.

> I would say that the mutex should ensure that no instructions
> From=20aother program post enter can issue until after the exit is
> called,

Basically, yeah: given

thread 1 does: A(); enter; B(); ... C(); exit; D();
thread 2 does: E(); enter; F(); ... G(); exit; H();

then the mutex - I'm talking abstract mutexes in general, now, not what
NetBSD's mutexes do - ensures that the F()...G() sequence occurs either
entirely before B() or entirely after C(), and, similarly, the
B()...C() sequence occurs either entirely before F() or entirely after
G().  (A() through H(), here, are arbitrary operations, not just
function calls, of course.  Writing them as function calls is just
notational convenience.)  But this applies to instruction issue, which
bears less relationship than one might wish to when stores reach global
visibility and when loads start and complete.

> but it then seems obvious that without memory barriers this isn't a
> useful guarantee.

Well, I wouldn't go that far, but it's less useful than it otherwise
could be.

In the abstract, it's perhaps better if the mutex operations do not
entail memory barriers; that way uses that don't need memory barriers
don't have to pay the costs of them, and the uses that do want memory
barriers can insert them themselves.  But, since few-to-none of the
people writing the relevant code will totally grok this stuff, and
since almost all of the uses will want the memory barriers, I think
having the mutex calls make memory-barrier promises is a Right Thing.

> It would be nice if someone who really gets this added a line to the
> mutex man page, ideally referring to the memory barrier specs.

I agree.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B