qio: Clean up locking
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 25 Mar 2016 15:26:25 +0000 (11:26 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 31 Mar 2016 20:53:42 +0000 (16:53 -0400)
commit9ec41115cb8312180eb81ecf0ac3588c313f4de3
tree6297af741e8ef8db9c3d44a97577566a341a483b
parent31ab477c31ec6fc8bb6ef749da3f19395988b7de
qio: Clean up locking

Locking was a bit of a mess, including qlocks and spinlocks.

For the most part, the ordering was qlock->spinlock, but most everything
was protected by the spinlock and the qlock didn't do much.

There are a few issues:

The rlock/wlock qlocks seem mostly to serialize rendez sleepers.  Plan 9
needed this; we do not.  There might be a 'thundering herd' wakeup effect
if you have a large number of sleepers (wake up just to see the condition,
vs sleeping on the qlock that doesn't get released until at least one
thread woke up).  If that's an issue, we can fix it later; maybe in rendez
or at least closer to the rendez.  The qlocks might also be 'protecting'
the spinlock, but it don't see much value in that.

The mess with 'should_free' can be ripped out too - we just free the block
in a couple cases, and now we're explicit about it.  That was nasty.

qwait() was doing weird things with locks too.  It internally unlocks for
you.  Surprise!  Instead I'll just have it lock for you when it returns -
no mystery.

The rlock might have been protecting things related to bl2mem, where we
briefly let go of the spinlock.  The qlock might have been preserving some
invariant (who knows?!).  I decided to just hold the spinlock across
bl2mem.  I avoided doing that in the past since that function could PF.
But we're busted regardless of whether we had a qlock or a spinlock; either
would deadlock if the PF handler tries to use the device to resolve the
fault.

Plus we have a host of memcpys and memmoves that touch user memory in qio.
We need to fix PFs overall - this patch should have made things no worse in
that regard (and hopefully much clearer).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/src/ns/qio.c