cap: fix issues with waserror and memory leaks
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 2 May 2019 01:19:11 +0000 (21:19 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 2 May 2019 01:19:11 +0000 (21:19 -0400)
commit67c08cbc5fff47cf22fd54a20e7d1ba0fbd0d2a5
tree707541b87329f7592c2f7205169831021cad0ea6
parent6a15d9678d1589d54cc7b697ebb2e60ac1bc0a10
cap: fix issues with waserror and memory leaks

The rule is that if you set a variable after a waserror(), that variable
needs to be volatile.  Otherwise the compiler may lose it.

It's not enough for the access inside the waserror() to be volatile,
since a write further down in the function may be stuck in a register.

Until we can get the compiler to realize a variable will be accessed in
both sides of the waserror() and flush it to the stack before calling
another function (which could throw), then we're out of luck.

To deal with it, the easiest thing in this case is to just do the
allocations first.

On a similar note, it looks like p was being leaked if there was an
error later in capwrite().  We just free it regardless (which may be a
bug), so we might as well free it right away.  It's already yanked out
of its data structure and just leaked.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/drivers/dev/capability.c