16 months agoqio: move copy_to_block_body() out of qio.c
Barret Rhoden [Wed, 5 Jun 2019 18:18:53 +0000 (14:18 -0400)]
qio: move copy_to_block_body() out of qio.c

It's more about blocks than queues, and I want to use it in an upcoming
block_ function.  And rename it while we're here.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoqio: remove CONFIG_BLOCK_EXTRAS
Barret Rhoden [Wed, 5 Jun 2019 15:29:03 +0000 (11:29 -0400)]

Using block extra_data is now mandatory.  If there are bugs with it,
we'll fix them.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoqio: check for leaked blocks
Barret Rhoden [Mon, 3 Jun 2019 18:13:26 +0000 (14:13 -0400)]
qio: check for leaked blocks

Whether a block is a singleton or a blocklist can be a little confusing.
This commit attempts to catch any freeb() calls on a block that is
actually part of a list.  So far, I haven't found any cases, so this is
merely precautionary.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoDo not call functions inside assert()
Barret Rhoden [Fri, 31 May 2019 18:45:52 +0000 (14:45 -0400)]
Do not call functions inside assert()

We ought to be able to delete all asserts and have no change to the

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoelf: limit the number of argc/envc
Barret Rhoden [Fri, 31 May 2019 18:39:54 +0000 (14:39 -0400)]
elf: limit the number of argc/envc

This is just a sanity check.  There are a few multiplications based on
these numbers, and this essentially checks for overflow too.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoelf: do not use variable length arrays on the stack
Barret Rhoden [Fri, 31 May 2019 18:35:09 +0000 (14:35 -0400)]
elf: do not use variable length arrays on the stack

To make matters worse, the size of these arrays was controlled by
userspace.  You could jump off the end of your stack, or even jump the
guard pages.

The long term fix is to yank all of this ELF loading out of the kernel.
In the short term, I just removed the on-stack arrays.  For remap(),
the easiest thing was to just remove the intermediate array and copy the
pointer values directly to userspace.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoelf: do not use nested functions
Barret Rhoden [Thu, 30 May 2019 22:26:47 +0000 (18:26 -0400)]
elf: do not use nested functions

There's no reason to use it, and all it does is make the code harder to

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agoRun default init script at boot when using defconfig
Aditya Basu [Wed, 29 May 2019 21:54:21 +0000 (17:54 -0400)]
Run default init script at boot when using defconfig

Signed-off-by: Aditya Basu <mitthu@google.com>
16 months agoCleanup GETTING_STARTED.md
Aditya Basu [Wed, 29 May 2019 20:46:55 +0000 (16:46 -0400)]

* Remove references to AkAROS_XCC_ROOT
* Explain use of AKAROS_TOOLCHAINS
* Remove section 3.4 on Busybox
* Fix a typo

Signed-off-by: Aditya Basu <mitthu@google.com>
16 months agoAdd AKAROS_TOOLCHAINS (XCC)
Aditya Basu [Wed, 29 May 2019 19:42:43 +0000 (15:42 -0400)]

* It points to the location where XCC toolchain (gcc + glibc)
gets installed.
    - XCC_ROOT was a particular toolchain (e.g. x86_64).
    - TOOLCHAINS is the directory for all toolchains, e.g. riscv, x86_64.
    - So TOOLCHAINS is the parent of the old XCC_ROOT.

**NOTE:** Delete your toolchain Makelocal and set AKAROS_TOOLCHAINS in
your environment. Then rebuild your toolchain.

Signed-off-by: Aditya Basu <mitthu@google.com>
16 months agoRemove use of AKAROS_XCC_ROOT (XCC)
Aditya Basu [Wed, 29 May 2019 18:19:56 +0000 (14:19 -0400)]
Remove use of AKAROS_XCC_ROOT (XCC)

Turns out it was only used to compute AKAROS_SYSROOT, which we
can compute directly with -print-sysroot.

Signed-off-by: Aditya Basu <mitthu@google.com>
16 months agovmm: x86: do not advertise support for TSC_ADJUST
Barret Rhoden [Fri, 24 May 2019 21:28:51 +0000 (17:28 -0400)]
vmm: x86: do not advertise support for TSC_ADJUST

This is relatively harmless, but Linux tries to touch this MSR early in
boot and we inject a GPF.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agovmm: refactor cpuid vmexit handling (XCC)
Barret Rhoden [Fri, 24 May 2019 20:53:00 +0000 (16:53 -0400)]
vmm: refactor cpuid vmexit handling (XCC)

This was a minor irritant anytime I looked at cpuid handling.  Even
though we just have one cpuid that userspace was checking, we shouldn't
have hardcoded the check.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agovmm: rename VMCALL_* -> AKAROS_VMCALL_* (XCC)
Barret Rhoden [Fri, 24 May 2019 20:21:46 +0000 (16:21 -0400)]
vmm: rename VMCALL_* -> AKAROS_VMCALL_* (XCC)

These are the same names I use in Linux 5.1.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agovmm: update the guest commandline for 5.1.
Barret Rhoden [Fri, 24 May 2019 20:18:02 +0000 (16:18 -0400)]
vmm: update the guest commandline for 5.1.

These changes are in accordance with my linux-guest patches on 5.1.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agovmm: remove the leading '%' from the printc vmcall
Barret Rhoden [Fri, 24 May 2019 20:16:33 +0000 (16:16 -0400)]
vmm: remove the leading '%' from the printc vmcall

The latest Linux akaros-guest prints the timestamp.  The '%' is
unnecessary now.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
16 months agovmm: remove verbose output
Barret Rhoden [Fri, 24 May 2019 20:15:27 +0000 (16:15 -0400)]
vmm: remove verbose output

A lot of those debugging prints were unused and cluttered the VMM's
early output, making it harder to find real bugs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: change parsecmd()'s size arg's type to size_t
Barret Rhoden [Tue, 21 May 2019 03:05:26 +0000 (23:05 -0400)]
9ns: change parsecmd()'s size arg's type to size_t

This is a leftover from Inferno/Plan 9, where ints are scattered about
where we should use a size_t.  Longs are a little better (64 bit vs 32),
but are still signed.

This commit changes parsecmd() and all of its callers.  Beyond the
ether->ctl and whatnot, there probably are other users who still convert
length to an int, which can cause problems.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoproc: don't throw from proc_get_set()
Barret Rhoden [Fri, 17 May 2019 03:04:35 +0000 (23:04 -0400)]
proc: don't throw from proc_get_set()

This was never actually throwing, since MEM_WAIT allocations are defined
to never return NULL.

Throwing from here was a minor issue, since profiler_setup() isn't set
up to handle throws anymore.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoproc: fix refcounting bug in proc_get_set()
Barret Rhoden [Fri, 17 May 2019 03:03:11 +0000 (23:03 -0400)]
proc: fix refcounting bug in proc_get_set()

You can't blindly incref when iterating over the procs.  You need to
hold the hash lock, then call kref_get_not_zero.  You're synchronizing
with __proc_free().

Reported-by: syzbot+4ea9ed2220ee4d513e0b@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agovmm: fix gva2gpa PCID mask bug
Barret Rhoden [Thu, 16 May 2019 20:50:33 +0000 (16:50 -0400)]
vmm: fix gva2gpa PCID mask bug

gva2gpa() walks the guest's page table.  It gets the page table from the
cr3.  However, it was not masking the PCID / ASID, so we'd end up
walking incorrectly.

This was a nasty one; after rebasing the linux-guest repo from 4.13 to
5.1, we'd crash during boot.

When Linux touched the IOAPIC, it would appear to fault at
0xffff8880003000000.  Checking the asm and registers showed it was
trying to access the fix_map location for the IOAPIC.  After confirming
the page tables were establish and were in use, I eventually realized
that maybe the Linux setup was fine, and we were making that memory
read, and EPT faulting.

At that point, it was a matter of tracing the execution and seeing
gva2gpa() failed.  At some point, our Linux setup starting using PCIDs,
such that the lower byte was 1.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agovmm: x86: set reserved bits in rflags for smp boot
Barret Rhoden [Thu, 16 May 2019 20:48:32 +0000 (16:48 -0400)]
vmm: x86: set reserved bits in rflags for smp boot

Again, this is the same problem as in commit:

8dc899e19d0f ("vmm: x86: Set the reserved bits in rflags"),

Where rflags was not set.  This time, it was the guest APs.  This should
be the last of it: single and multicore guests, single and multicore

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agomm: remove the path arguments to foc_abs_path()
Barret Rhoden [Sun, 12 May 2019 23:03:35 +0000 (19:03 -0400)]
mm: remove the path arguments to foc_abs_path()

I think the VFS version of foc_abs_path() needed the buffer for the
storage of the absolute path, since the VFS didn't maintain that
internally.  9ns maintains that pointer, so we can just return it.

The lifetime of that chan's name should be the lifetime of the chan
itself.  Although I can imagine cases where that isn't true, e.g. if you
walk a chan to another chan, hopefully those chans are externalized to
the rest of the system, i.e. only used in chan.c during walk().  Keep in
mind walks from O_PATH chans.

If that turns out to not be the case, then we can copy it out, though
even then we'd need to understand when the chan's name is changing,
since there's no reason it can't be changed during foc_abs_path().

Similarly, I'd like to know if we ever have a chan exposed to the rest
of the system that has no name.  The answer to this is probably related
to whether or not the chan's name can change.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoRename error_assert() -> error_check()
Barret Rhoden [Sun, 12 May 2019 22:24:35 +0000 (18:24 -0400)]
Rename error_assert() -> error_check()

If asserts fail, that's a kernel bug.  The error_check() pattern is just
shorthand for "if (foo) error(...)", which are not asserts.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoprof: fix disgusting synchronzation
Barret Rhoden [Sun, 12 May 2019 22:00:43 +0000 (18:00 -0400)]
prof: fix disgusting synchronzation

The profiler's sync code was always an annoyance - the first version was
nasty and I found bugs with it.  The second version (current code) had
layers of krefs and qlocks and whatnot, obfuscating things.  I didn't
see the bug at the time, but syzbot found the bug.  Absence of evidence
is not the evidence of absence.

The root of the issue was that the kref was used to handle the
tear-down, but the open / setup code assumed a close / cleanup was
completed.  If a core kept a kref around between a quick close-open
pair, then we'd crash.  Specifically, this would die:

Core 1 Core 2
  set ref = 1
start BT sample
kref_get (ref == 2)
  decref, ref == 1

  panic!  (ref != 0)
eventually decref

Fixing it requires blocking close / cleanup until all of the users are
done (users being the sampler pushers).  That's a great use for RCU.

This commit replaces the kref with RCU, and fixes a bunch of other nasty
things along the way.  To do it properly, I created struct profiler to
encapsulate the qio and the per-core array, and protected that entire
thing with RCU.

This resulted in a lot of cleanups.  Various assertions and checks for
the existence of profiler_queue and the cpu buffer array all disappear.
I also explicitly documented the synchronization rules, and got rid of
the superfluous profiler mutex.

Additionally, a lot of the error handling goes away.  Some of it was due
to completely unnecessary use of waserror() - e.g. catching errors for
functions that don't throw.  There was also an unmatched waserror() in
the old code.  That's all gone.

Other minor fixups:
- kprof couldn't handle an error in profiler_setup().  If it failed,
we'd just say the profiler was opened.
- kmalloc(x, 0) -> kmalloc(x, MEM_ATOMIC)
- WRITE_ONCE() for the unsynched configuration variable writes.  Note
that no one in our codebase even uses those, and their usage is a little

Anyway, there might be some bugs here still, but hopefully it's a little
better and more clear.

Reported-by: syzbot+e8998ed113c341947438@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoevent: fix divide by 0 in send_event()
Barret Rhoden [Thu, 9 May 2019 00:40:27 +0000 (20:40 -0400)]
event: fix divide by 0 in send_event()

SCPs have num_vcores == 0, which triggers a divide by zero.

You can tell how old the ROUND_ROBIN event style is - it's never been
used on an SCP.  Back in the day, SCPs couldn't even receive events.
Now they have vcore context and the ability to run a 2LS.

Reported-by: syzbot+a20f4107d5ec7009c1c4@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: fix format-string vulnerability in cmderror()
Barret Rhoden [Thu, 9 May 2019 00:26:12 +0000 (20:26 -0400)]
9ns: fix format-string vulnerability in cmderror()

In cmderror(), the genbuf is filled with user-controlled data via the
seprintf() calls.  That data could consist of a %s.  That genbuf was
passed to error(), which takes a format string.  Thus userspace could
set the format string passed to error, triggering a page fault (at

Reported-by: syzbot+36f58f45c1902ffdca18@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: don't pass user pointers for 'spec'
Barret Rhoden [Thu, 2 May 2019 13:50:55 +0000 (09:50 -0400)]
9ns: don't pass user pointers for 'spec'

Spec is often passed directly to error(), and thus snprintf.  Right now,
we don't actually pass a user pointer spec.  This comment tracks the one
location we could in the future.

Note that when you bind '#dev.spec', that string is copied in to the
kernel and checked.  That's in namec().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agosd: fix error string arguments
Barret Rhoden [Thu, 2 May 2019 13:47:22 +0000 (09:47 -0400)]
sd: fix error string arguments

Both cases had a %s but were lacking a corresponding char * argument.
If we ever threw those errors(), we'd probably page fault.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agocons: disable dangerous conswrites()
Barret Rhoden [Thu, 2 May 2019 13:45:30 +0000 (09:45 -0400)]
cons: disable dangerous conswrites()

We don't use either of those #cons variables.  consctl should be
rewritten, or just outright removed.  sysctl looked like it was leaking
memory and falling through to another case.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoregress: use parsecmd() instead of strncmp on user pointers
Barret Rhoden [Thu, 2 May 2019 03:17:41 +0000 (23:17 -0400)]
regress: use parsecmd() instead of strncmp on user pointers

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agokprof: use parsecmd() instead of strncmp on user pointers
Barret Rhoden [Thu, 2 May 2019 03:09:45 +0000 (23:09 -0400)]
kprof: use parsecmd() instead of strncmp on user pointers

The string passed to error("%s") was a user pointer.  We shouldn't even
be using manual strncmps and whatnot on user pointers - they might be
able to give us a pointer right below ULIM.

One fix for the strncmp checks would be to use MIN(write_amt,
static_len), since we know sys_write() made sure write_amt bytes were

But since we already called parsecmd(), let's just use it.

Reported-by: syzbot+75a997a9a55827b3871d@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: make kstrdup() actually atomic
Barret Rhoden [Thu, 2 May 2019 02:23:15 +0000 (22:23 -0400)]
9ns: make kstrdup() actually atomic

The specific case that triggered this was multiple mounts on
 #cons/sysname.  Mount does a dev->write, which led to racy calls to
kstrdup on the global sysname.

Reported-by: syzbot+75a997a9a55827b3871d@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoprintk: check for user pointers in format string parameters
Barret Rhoden [Thu, 2 May 2019 01:40:27 +0000 (21:40 -0400)]
printk: check for user pointers in format string parameters

These may be a potential source of vulernability.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoprintk: rename the string local var 's'
Barret Rhoden [Thu, 2 May 2019 01:23:47 +0000 (21:23 -0400)]
printk: rename the string local var 's'

I'll use p for some sanity checks.  I'd rather have compiler support

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoAdd warn_on_user_ptr()
Barret Rhoden [Thu, 2 May 2019 01:22:54 +0000 (21:22 -0400)]
Add warn_on_user_ptr()

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agocap: fix issues with waserror and memory leaks
Barret Rhoden [Thu, 2 May 2019 01:19:11 +0000 (21:19 -0400)]
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>
17 months agocap: use MEM_WAIT for allocations
Barret Rhoden [Thu, 2 May 2019 01:10:10 +0000 (21:10 -0400)]
cap: use MEM_WAIT for allocations

Either wait or check the return value.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agocap: fix format-string vulnerability
Barret Rhoden [Thu, 2 May 2019 00:16:06 +0000 (20:16 -0400)]
cap: fix format-string vulnerability

It looks like the old code was trying to use snprintf() to sanitize the
user-provided strings.  That worked, but then we passed it to error(),
and the string passed to error() is *itself* a format string.  So in
attempting to make things more secure, we botched it.

Note that from and key are not user-pointers, and we know they are
null-terminated.  Our printf family of functions (and thus our error())
can handle null-terminated strings made of user-data, but not user
*pointers.*  By default, snprintf() does an unbounded strnlen() on the
string pointer, which could look beyond the region checked by

Reported-by: syzbot+871c0525c81bbe0e93a5@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoRemove extraneous sysfd2path()
Barret Rhoden [Tue, 30 Apr 2019 00:54:33 +0000 (20:54 -0400)]
Remove extraneous sysfd2path()

We already have sys_fd2path(), and no one was using sysfd2path().  The
latter, which we are removing, is the Plan 9 implementation, I think.

Arguably, the one we are removing is a little faster, since it doesn't
invoke the snprintf() mechanisms and is a straight memcpy, but it also
doesn't handle the "no string" case yet.  If we ever want to make
sys_fd2path() faster, we certainly can.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoFix null-pointer deref in SYS_readlink()
Barret Rhoden [Tue, 30 Apr 2019 00:44:50 +0000 (20:44 -0400)]
Fix null-pointer deref in SYS_readlink()

We weren't checking the return value, which is NULL when namec() fails
to look up the path.

Incidentally, paths that go through copy_in_path() can be "", at least
under the current code.

Reported-by: syzbot+c9d58a7d1582d003ea18@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: ensure the parent of a rename target is a directory
Barret Rhoden [Tue, 30 Apr 2019 00:21:08 +0000 (20:21 -0400)]
9ns: ensure the parent of a rename target is a directory

We subtracted the last element from the walk, but never checked that the
result of the walk was a directory.

Reported-by: syzbot+7e385d5c8a674a08d28a@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months agoFix unsanitized input to remove_fd_tap()
Barret Rhoden [Tue, 30 Apr 2019 00:00:48 +0000 (20:00 -0400)]
Fix unsanitized input to remove_fd_tap()

Reported-by: syzbot+23841a68e22cc895cab7@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: treat opens of symlinks as EINVAL
Barret Rhoden [Wed, 24 Apr 2019 01:58:26 +0000 (21:58 -0400)]
9ns: treat opens of symlinks as EINVAL

ELOOP was a little confusing.  The errstr helped though.  =)9ns: treat
opens of symlinks as EINVAL

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: move the symlink check after the mount check
Barret Rhoden [Wed, 24 Apr 2019 01:52:17 +0000 (21:52 -0400)]
9ns: move the symlink check after the mount check

Although you can't bind a symlink (so that it is the domount side of a
mount point), the code is a bit cleaner if we do the symlink check after
the 'mount/nomount' spot.

Also, if we ever build in support for binding symlinks (src_path / WHAT)
onto the namespace, then we'll already have support for that on the
intermediate path names in a walk.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: make the diagnostic output of bind saner
Barret Rhoden [Wed, 24 Apr 2019 01:28:38 +0000 (21:28 -0400)]
9ns: make the diagnostic output of bind saner

The biggest issue was the X -> Y output; it was the opposite of what you
see from a ls -l from a symlink.  The arrow had meant "put X onto Y",
but in symlink terms, that is "X points to Y" which is the opposite.

Plus, you could do something like bind -ac and only the -a was noticed.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
17 months ago9ns: do not allow binding a symlink onto any other name
Barret Rhoden [Wed, 24 Apr 2019 01:07:22 +0000 (21:07 -0400)]
9ns: do not allow binding a symlink onto any other name

Due to how walk() handles mount points, allowing binds pointing to
symlinks is difficult enough to warrant not supporting that feature.

Specifically, walk() only follows mount points for intermediate parts of
a path, e.g. /this/this/and/this/but-not-this.  If we allowed binding to
symlinks, any of those mounts could be symlinks.  The intermediate ones
are fine, but since walk() does not call domount() and follow the last
path name, we could be sitting on a symlink when walk() returns.

This might not be a huge problem, but all callers of walk() would need
to handle this - in particular namec().  Most everyone calls domount(),
so it is tempting to have domount() call walk_symlink().  However, note
the existing of undomount() (used by dotdot).  You can undo a mount, but
you can't undo a symlink follow.  So I bet you could concoct a situation
where you wanted to undomount(), but the mount/bind was to a symlink and
you're busted.

Given that binds and symlinks are largely independent implementations of
a similar concept, I don't see a need to allow a bind to point to a

The naming around binding and symlinks can be a little confusing.  To be
clear, the scenario is:

$ ln -s file symlink
$ /bin/bind symlink /some/other/name

Both of these are in the style:

- ln -s calls it TARGET and LINK_NAME
- Our bind calls it SRC_PATH and ONTO_PATH
- Plan 9's bind called it NEW OLD
- Linux's mount --bind calls it OLD NEW
- Another way to think of this is WHAT WHERE, especially when you think
  of binding devices into the namespace.

This means that when you walk to /some/other/name, you'll get the
symlink, and with the various 'follow' flags set, you'd expect to get
'file'.  Prior to this commit, walk() would get the symlink, not the
file.  Now, the bind just fails.

Note you can still bind 'from' a symlink, i.e. ONTO_PATH.  So you could
do this:

$ ln -s file1 symlink
$ cat symlink # get file1's contents
$ /bin/bind file2 symlink
$ cat symlink # get file2's contents

The file 'symlink' is still a symlink, but 'file2' was bound over it in
the namespace.  Someone else's namespace will still see symlink ->
file1.  If you do a stat or ls -l in the namespace with the bind, you'll
just see the info for 'file2'.

Reported-by: syzbot+2b1a1f196f3612be7660@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoFix markdown inline code
Robin Gögge [Sat, 13 Apr 2019 13:15:43 +0000 (15:15 +0200)]
Fix markdown inline code

Signed-off-by: Robin Gögge <r.goegge@outlook.com>
18 months agovmm: make output for failed vmexits more threadsafe
Barret Rhoden [Thu, 11 Apr 2019 21:10:04 +0000 (17:10 -0400)]
vmm: make output for failed vmexits more threadsafe

If you had concurrent threads vmexit and the 2LS was unable to handle
the exits, you'd get an unintelligible mess.

This commit removes some unnecessary info - namely all of the info in
handle_vmexit() - and protects all of the output with a single lock.
It's not super elegant, and other printing can interfere with the
output, but it helps when there is a coordinated failure across numerous

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agovthread: x86: set the reserved bits in rflags
Barret Rhoden [Thu, 11 Apr 2019 20:47:06 +0000 (16:47 -0400)]
vthread: x86: set the reserved bits in rflags

This fix is the same as commit 8dc899e19d0f ("vmm: x86: Set the reserved
bits in rflags"), which fixed vmrunkernel.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoparlib: have 2LS libraries #include parlib/stdio.h
Barret Rhoden [Thu, 11 Apr 2019 21:06:06 +0000 (17:06 -0400)]
parlib: have 2LS libraries #include parlib/stdio.h

For painful reasons, if you call any functions related to printf from
vcore context or from a uthread with notifs disabled, you need to use
our special fprintf macros.  You get those via parlib/stdio.h, which
also #includes the real stdio.h.

Most code that this could happen to come from parlib, pthread, or vmm.
This commit just changes all of their headers to include parlib/stdio.h.

This is far from the best approach, but it stops the bleeding.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoSanitize vcoreid from untrusted sources
Barret Rhoden [Thu, 11 Apr 2019 00:57:15 +0000 (20:57 -0400)]
Sanitize vcoreid from untrusted sources

Reported-by: syzbot+a21358b54760bd84b850@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agomm: check for valid prot settings (XCC)
Barret Rhoden [Tue, 9 Apr 2019 00:31:44 +0000 (20:31 -0400)]
mm: check for valid prot settings (XCC)

Prior to this commit, we were not checking 'prot' in mmap() and
mprotect() for extra bits.  The user could put arbitrary bits into a
VMR's prot.  We only checked the valid bits, since commit ee6bef89ffdb
("mm: fix checks for PROT_NONE").

One potential issue is buggy programs that had been passing extra bits.
Those will fail early now.

Tested with ssh and get_html.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agomm: remove unused MAP_ and PROT_ flags (XCC)
Barret Rhoden [Mon, 8 Apr 2019 23:41:01 +0000 (19:41 -0400)]
mm: remove unused MAP_ and PROT_ flags (XCC)

mmap() and mprotect() have a bunch of flags that we don't use, such as
PROT_GROWSDOWN and MAP_DENYWRITE.  These only existed in the kernel
interface, yet we never actually use them.

This commit removes those flags from the kernel interface.  Userspace
can still pass them to us - they can pass anything after all.  We won't
honor them and may throw errors if we get them.  I'd rather not export
definitions for the kernel interface that the kernel doesn't know about.

Note that glibc still has these common flags in
glibc-2.19-akaros/sysdeps/akaros/bits/mman.h, which is Linux's glibc
header.  Replacing that outright at the moment needs some work.  For
instance, malloc calls __madvise() and whatnot.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agomm: fix checks for PROT_NONE
Barret Rhoden [Mon, 8 Apr 2019 23:30:19 +0000 (19:30 -0400)]
mm: fix checks for PROT_NONE

You gotta love PROT_NONE, O_RDONLY, and any of these flags whose value
is zero.

The old code assumed that the only options for 'prot' were mutually
exclusive with PROT_NONE, such that we could check prot == PROT_NONE
when we really meant "has no access".  We checked for equality, since we
can't do (prot & PROT_NONE), since PROT_NONE == 0.

However, checking prot == PROT_NONE is wrong: we have other flags, like
PROT_GROWSDOWN.  Arguably, we shouldn't use those flags - I'll remove
them shortly.  Regardless, using a helper cleans up the code.

Reported-by: syzbot+aafc3433b89c900f8fe1@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoRemove getcallerpc()
Barret Rhoden [Mon, 8 Apr 2019 13:42:28 +0000 (09:42 -0400)]
Remove getcallerpc()

It did nothing and was just confusing.  For example, the panic message
for a double-close was just: "cclose 0x0000000000000000".

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoFix refcounting problem in walk_symlink()
Barret Rhoden [Mon, 8 Apr 2019 13:19:16 +0000 (09:19 -0400)]
Fix refcounting problem in walk_symlink()

The old code would double-close 'symlink' if it ever got into the "walk
succeeded but we were still on a symlink" case.

Recall that walk_symlink() either walks all the way, or not at all.  If
the old code (deleted) failed, we were supposed to close symlink.
However, there was a case where walk_symlink would fail, but it would
also close the chan passed in: when the sub-walk succeeded, but
walk_symlink() still failed.  How could that fail?  With a symlink loop.

If that sounds confusing, it's because it is.  There are actually two
spots of recursion, which might not even have been clear to me when I
wrote this.  The main recursive path is walk -> walk_symlink -> walk ->
walk_symlink.  We normally never got to the "walk succeeded, then call
walk_symlink" (deleted).  We usually only called walk_symlink() from
*within* walk itself.

You could trigger this situation with a no_follow symlink
(rename/remove, flags Aremove, flags no_follow).  Syzkaller basically
did this:
ln -s x x
rename x/x whatever
So we were walking the first x, had no_follow set, so walk ->
walk_symlink for the first x.  Since there were more names in the
main/outer namec, we'd get past the first no_follow.  Then that second
walk() would be for "../x", where no_follow would kick in, since there
were no longer any names left.  That walk_symlink() would return the
syml passed in, which appeared to walk to be a success (which it was).

Anyway, this was calling the buggy post-successful-walk() part of
walk_symlink().  The first fix I had was to only cclose(symlink) when that
interior walk_symlink() succeeded.  Although that fixed the bug
(walk_symlink either succeeds xor closes, so don't close on success),
the real problem was having that code at all.

If walk() lands on a symlink, walk itself should try to deal with it (by
calling walk_symlink()).  If walk returns (success or failure), we
should consider the walking of that symlink to be done, one way or
another.  If it is no_follow, we might be on a symlink (if last in the
path).  If it was a mount_point, we could be on a symlink too.

That whole "we're still on a symlink, let's walk it again" was busted,
and it would break when we had no_follow set globally and tried to
follow a legit intermediate symlink that had more than one link to
follow (but not 8 - the max).  And it was confusing.  Hopefully this
code makes a little more sense - esp when realizing that walk() sorts
out symlinks by calling walk_symlink().  walk_symlink() shouldn't call
itself, but it can call walk().  Up to 8 times.

Reported-by: syzbot+9eec51df84779065d6de@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoClean up and clarify slim_setjmp() / waserror()
Barret Rhoden [Wed, 3 Apr 2019 19:21:15 +0000 (15:21 -0400)]
Clean up and clarify slim_setjmp() / waserror()

Any time you use a variable inside a waserror() block that has been
written since the waserror() / setjmp(), that variable must be marked

The bool err; in slim_setjmp served little purpose, other than

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoRemove unnecessary panic() in rread()
Barret Rhoden [Wed, 3 Apr 2019 03:34:33 +0000 (23:34 -0400)]
Remove unnecessary panic() in rread()

Ultimately, we throw an error when attempting to do a short read on a

Reported-by: syzbot+fbc1784c73dfdf878652@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agox86: Make the MP tables and IOAPIC output slightly more useful
Barret Rhoden [Thu, 28 Mar 2019 19:46:45 +0000 (15:46 -0400)]
x86: Make the MP tables and IOAPIC output slightly more useful

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agox86: Try to fix MP table I/O interrupt assignment entries
Barret Rhoden [Thu, 28 Mar 2019 19:40:43 +0000 (15:40 -0400)]
x86: Try to fix MP table I/O interrupt assignment entries

I have a desktop PC with two IOAPICs, 8 and 9, and the IOINTR entries do
not specify valid APIC IDs (0 and 2).  ACPI agrees the IOAPIC ids are 8
and 9.

This method works at least for the lower IOAPIC (id = 8) on my deskop.

You'd have to have broken MP tables to even get this far.  Prior to this
commit, PCI devices would complain about not being able to set up an IOAPIC

These changes will make those busted IOINTRs appear to be correct ones,
but there's no guarantee that the hardware is actually wired that way.
might think you're using an IOAPIC route when you're actually using the
wrong one.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agox86: Make an editable copy of the MP tables
Barret Rhoden [Thu, 28 Mar 2019 19:39:31 +0000 (15:39 -0400)]
x86: Make an editable copy of the MP tables

I have a machine that appears to have some bad entries.  I'd like to
just edit the table in place, but there's no guarantee the tables are in
actual RAM.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoSet up git blame to ignore the "8-space-tab commits"
Barret Rhoden [Wed, 27 Mar 2019 22:01:02 +0000 (18:01 -0400)]
Set up git blame to ignore the "8-space-tab commits"

If you're using git hyper-blame, the .git-blame-ignore-revs file should
work; that is their default.

If you're using my patches for upstream Git, the git config settings
will work.  If the interface for my upstream stuff changes, or an
alternate version gets implemented, I'll update the script.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoAdd scripts/one-time-setup.sh
Barret Rhoden [Wed, 27 Mar 2019 21:42:30 +0000 (17:42 -0400)]
Add scripts/one-time-setup.sh

This will contain sanity checks and steps that should run once per git

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoFix 8 space tab formatting for non-C files
Barret Rhoden [Tue, 26 Mar 2019 21:34:41 +0000 (17:34 -0400)]
Fix 8 space tab formatting for non-C files

I missed all of these files when I handled the .c and .h files.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
18 months agoTreat tabs as having eight spaces instead of four
Barret Rhoden [Tue, 12 Mar 2019 23:41:50 +0000 (19:41 -0400)]
Treat tabs as having eight spaces instead of four

For whatever bad reason, we chose to treat tabs as four spaces instead
of eight.  e.g. in vim, tabstop=4.

That's a huge pain - both when dealing with other tools and when
switching between projects.  I don't particularly like having
per-project vim settings and whatnot.  Plus, that's a bit harder for
other people who look at our code and have their vim/emacs set to 8
space tabs.

I had regretted that for a long time, but I didn't want to make the
change for two reasons:

1) With other people working on the project, changes of this sort can
lead to merge conflicts.  Since I'm the only one working on it, for the
most part, this isn't a concern.

2) The bigger reason is that major reformatting changes break git blame.
However, there are tools that can ignore commits when running git blame.
Chromium has git hyper-blame.  I thought that feature ought to be baked
into git, so I have a patchset out for git to do so.  Either way, I'll
either have my own patched git or the feature will get merged.  In a
future commit, I'll have instructions for how to use that feature.

A lot of our files didn't need too much attention, due to our old
"spaces for formatting" policy.  I didn't change those to use tabs
instead of spaces for the formatting either.  I expect newer code will
just do whatever people's editors do.  I didn't want to change more
lines than were needed, and the code looks the same either way.

The biggest offenders were indented comments.  Structs with
column-aligned members needed some work too.  I did most of that stuff
manually, since the tools do a mediocre job.

Since I was making changes, I also fixed up the switch-case indenting:
don't do an extra level of indentation for the case keywords.  Doing
this now actually helped with the 8-space tab change, since switch
statements got a few spaces to work with.

A few of the kernel's C files were so badly messed up that I just used
clang-format on them.  Same for Plan 9 files that had been
clang-formatted before and hadn't been heavily modified by us.
Clang-format caused a few problems with its "alphabetized headers"
policy.  That was fun.

Higher-quality (subjectively) code didn't need as much work as older,
poorer code.  Specifically, code with way too many levels of indentation
looks even worse than before - that's actually a benefit of 8-space
tabs: it tells you when your code is bad.  A lot of that older code
needs a more serious refactoring, which this commit does not do.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agoCheck event_queue pointer addresses
Barret Rhoden [Wed, 6 Mar 2019 16:47:29 +0000 (11:47 -0500)]
Check event_queue pointer addresses

We had a couple checks in send_event(), mostly warnings and prints.
This commit changes those warnings to one panic, and pushes the error
handling closer to userspace.

Note that there's not much we can do about a bad pointer in a syscall
struct, other than "silently" fail.  It's almost always a bad user bug,
hence the informational print.

Also note that the kernel can still fault on an unmapped, paged out
address in userspace.  None of that is sorted.  This is just the sanity
checks to make sure we aren't give a kernel pointer.  It also catches
any very low pointers, below the MMAP_LIM.  (So null pointers and

Reported-by: syzbot+ab67ae285c93a8d288a7@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agodevproc: check for #mnt instead of #M
Barret Rhoden [Wed, 6 Mar 2019 16:43:04 +0000 (11:43 -0500)]
devproc: check for #mnt instead of #M

We missed this when changing the names of all of the devices.  All 9ns
device names are strings, not single characters.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agoFix data leak in fs_file_write()
Barret Rhoden [Sat, 2 Mar 2019 01:13:31 +0000 (20:13 -0500)]
Fix data leak in fs_file_write()

The user could give write() the valid address of a non-resident page,
particularly one in a file-backed region.  The kernel would fail to read
from it, and thus not write any data into the page cache.  The page
cache page is uninitialized, and thus contains arbitrary kernel data.

This is a stopgap, until I sort out handling page faults in the kernel -
particularly on file-backed virtual addresses.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agoCheck read() and write() for offset + count wraparound
Barret Rhoden [Sat, 2 Mar 2019 00:50:43 +0000 (19:50 -0500)]
Check read() and write() for offset + count wraparound

If you gave a file a very large count and the sum offset + count wrapped
around, you could confuse the system into thinking you had a smaller

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agoCheck safety of user pointer syscall arguments
Barret Rhoden [Sat, 2 Mar 2019 00:43:19 +0000 (19:43 -0500)]
Check safety of user pointer syscall arguments

Most arguments, such as a path name, are copied into the kernel.
Buffers used in read() and write() are passed deeper into the kernel
as-is.  Later on, the devices are supposed to check the pointers, often
doing a safe operation such as copy_from_user().

fs_file_write() was doing that, however the assertion at the end of the
loop was failing.  If buf + count wrapped around, we'd skip the loop
entirely and trigger a panic.

For safety's sake, we ought to just check the range early on.  The
is_user_r{,w}addr() checks can handle wraparound as well as making sure
the region is safe.

There were a few other syscalls that didn't have checks or didn't have
errstrs for the message.  This commit fixes them all.

Reported-by: syzbot+7a8e2903ce1233ffcd3d@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
19 months agoHave abort_sysc() take a uintptr_t instead of a struct sysc pointer
Barret Rhoden [Sat, 2 Mar 2019 00:40:46 +0000 (19:40 -0500)]
Have abort_sysc() take a uintptr_t instead of a struct sysc pointer

The struct sysc pointer is not dereferenced.  By making it a uintptr_t,
it is more clear that the value is used as a number, not a pointer.
abort_sysc() uses it for a pointer equality check.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
20 months agoPin ktasks to core 0
Barret Rhoden [Wed, 30 Jan 2019 17:03:13 +0000 (12:03 -0500)]
Pin ktasks to core 0

Kthreads can migrate due to the hardcoded policy of "run kthreads on
whichever core woke them up."  This is technically a source of
interference for any MCP - consider a process that does as SYS_block /
kthread_usleep on core 6, then yields.  The alarm goes off on that core
and interferes with whoever is there.  The core timer IRQ is one issue,
and the kthread scheduling is another.

That kthread scheduling issue is worse for ktasks, since they are long

This commit ensures that ktasks only run on core 0.  Eventually, we will
probably want ktasks to run on all sorts of cores - consider polling the
NIC / driving the NAPI stack on a dedicated core.  The kernel alarm
service was briefly (out-of-tree) done with per-core ktasks.  For now,
think of ktasks as having affinity to core 0.

This is all a scheduling choice, so arguably we should be calling out to

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
21 months agoFix builds without CONFIG_SEMAPHORE_DEBUG
Barret Rhoden [Thu, 10 Jan 2019 22:02:13 +0000 (17:02 -0500)]

Earlier, I moved to using empty C functions instead of macros for the
cases where we have debugging turned off.  However, I still had the
CVs/SEMs conditionally including the 'db' struct.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoAdd a monitor debug function for rendez waiters
Barret Rhoden [Tue, 18 Dec 2018 20:56:58 +0000 (15:56 -0500)]
Add a monitor debug function for rendez waiters

When debugging, it's helpful to be able to tell what is waiting on a
particular rendez.  "db rv 0xWAITER" will do the trick.

Like many monitor commands, this is dangerous.  Not only will it cast
whatever you pass it to an alarm_waiter, but even if you don't mess up,
there's no telling that the alarm isn't currently firing and unwinding
the stack.  That being said, it's been useful for me.


(akaros) / $ m alarm pcpu
PCPU Chains:  It is now [    189.392342216]
Chain 0xffffffffcc683c48:  earliest: [    189.399452912] latest: [    482.049028825]
Waiter 0xffffffffcc683ac0, time [    189.399452912] (0x0000008cc62c95fa), func 0xffffffffc205a740 (__ksched_tick)
Waiter 0xfffffff000097dd8, time [    189.416393761] (0x0000008cc965c92b), func 0xffffffffc20586e0 (rendez_alarm_handler)
Waiter 0xfffffff0000a9c98, time [    482.049028825] (0x000001664a5eef19), func 0xffffffffc20586e0 (rendez_alarm_handler)
Chain 0xffffffffcc683f08:  earliest: [    189.477399144] latest: [    189.477399144]
Waiter 0xfffffff0000a6cb8, time [    189.477399144] (0x0000008cd50165fa), func 0xffffffffc20586e0 (rendez_alarm_handler)

(akaros) / $ m db rv 0xfffffff0000a6cb8
-------- kth #I0tcpack ----------

Backtrace of kernel context on Core 0:
 #01 [<0xffffffffc20145ab>] in cv_wait_and_unlock
 #02 [<0xffffffffc2014651>] in cv_wait
 #03 [<0xffffffffc20585cd>] in rendez_sleep_timeout
 #04 [<0xffffffffc2013d72>] in kthread_usleep
 #05 [<0xffffffffc20327a4>] in tcpackproc
 #06 [<0xffffffffc2013274>] in __ktask_wrapper
 #07 [<0xffffffffc2063bad>] in process_routine_kmsg
 #08 [<0xffffffffc205d59e>] in __smp_idle

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoparlib: Fix the use-after-func issue
Barret Rhoden [Tue, 18 Dec 2018 18:35:29 +0000 (13:35 -0500)]
parlib: Fix the use-after-func issue

Same as in the kernel, the parlib alarm service was touching the waiter
struct after the function ran.  We were doing this to know when the
function was complete when we were unsetting the alarm.  However, this
complicates the code of any client, since the completion of the function
isn't proof that the struct won't be reused.

See commit 47c2cf2efd4e ("futex: Call unset_alarm() before freeing the
awaiter") for a bug caused by this, and commit c62a28c78976 ("alarm:
Force unset_alarm to grab the CV lock")

The fix is the same as in the kernel - use the tchain->running variable
to track when a handler is running.

We're using the CV lock directly - userspace CVs don't have the same
interface as the kernel where you can tell it to use another lock.  And
we don't really need that interface, especially given that userspace CVs
are typically used for mutexes.

Given the slight nastiness associated with signalling a uth CV that uses
the CV lock, specifically that we want to unlock before waking the
uthread, I tried skipping the CV completely and just yielding - in
effect a busy-wait with a uthread_yield (sched_yield actually, which is
safe since we're an MCP if we ever unset during an alarm handler,
assuming one never unsets during their *own* alarm handle)).  However,
at least in qemu for some Go tests, some tests timed out too frequently.
My guess is that alarms were delayed too much by the busy waiting.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoalarm: Make the debugging output useful
Barret Rhoden [Mon, 17 Dec 2018 18:35:53 +0000 (13:35 -0500)]
alarm: Make the debugging output useful

TSC ticks are great and all, but it really helps to have it in a more
decipherable scale, such as seconds/nsec since boot.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Remove irq_state from sem_.*irqsave's interface
Barret Rhoden [Mon, 17 Dec 2018 16:04:57 +0000 (11:04 -0500)]
kth: Remove irq_state from sem_.*irqsave's interface

If disable_irqsave() and enable_irqsave() are in the same function, you
don't need to have the state passed in.

I stumbled on this while looking into whether or not CVs could drop the
irqstate as well.  The short version is 'no'.

Our kernel CVs just use spinlocks.  The particular lock and use case of
the CVs is up to our caller, so whether or not that lock is used from
IRQ context is beyond our control.

It would be nice to be able to use the functionality of
spin_lock_irqsave() to track whether or not we need to restore IRQs when
we return.  However, we unlock and relock that spinlock during the
process of waiting and restarting.  At that point, any information about
whether or not we should reenable IRQs is gone.  Thus we need to track
it with irqstate.

Note that the cv_wait code tracks whether or not IRQs were enabled *at
the moment*, but we also need to know if IRQs were enabled at the point
of the cv_lock_irqsave() and to carry that information over to

Also, none of the CV callers are from IRQ ctx anymore.  At most, all are
from RKMs.  When analyzing CVs, we only care about the wakeup side too
- you're not allowed to sleep from IRQ context.  And no one even calls

I considered removing the CV irqsave functions (and sems), but given the
flux in alarm code, there might come a time where we kick CVs from IRQ
context again, to include immediate kernel messages.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Remove irq_okay from sems and CVs
Barret Rhoden [Fri, 14 Dec 2018 22:46:11 +0000 (17:46 -0500)]
kth: Remove irq_okay from sems and CVs

It wasn't necessary.  The only use for it was one assertion.  If that
assert would have failed, then the spinlock code will also fail
(assuming SPINLOCK_DEBUG is on).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoalarm: Handle the tchain in RKM context
Barret Rhoden [Tue, 13 Nov 2018 02:34:41 +0000 (21:34 -0500)]
alarm: Handle the tchain in RKM context

The root issue is that we can't touch the alarm after it finished, yet
we also want to know when it has completed.  The way to do this is with
a layer of indirection!  (sort of - just with a pointer).  We can keep a
pointer that tracks the handler we're working on.

Don't forget - we want to run the handlers without holding the lock too,
which makes setting an alarm from a handler easier.  And it might avoid
deadlocks, such as the ones we saw in userspace with futexes.

To do all of this, we need to synchronize on that pointer, and it's
basically part of the tchain.  We want to manipulate the handlers and
the tchain while holding the lock, and run with the pointer set.  This
couples the execution of the locks with the processing of the tchain.
The old code just fired off a bunch of RKMs and forgot about them - we
can't forget now.

The answer here is to run the tchain handler as an RKM itself.  The
easiest way is to have __trigger_tchain send the core an RKM to
run_tchain.  Initially had a per-core ktask that looped and slept on a
CV, and the IRQ kicked the CV.  Just using the RKM directly is a little
faster and simpler.  It also means we won't have to worry about it if we
ever do special things with ktasks, like scheduling, priority, affinity,
etc.  The one slight downside is we might get multiple RKMs on the same
core to run the tchain.  That's pretty minor, and harmless from a
correctness perspective.

Also, since we're not touching the lock in IRQ ctx, we probably can make
it a non-irqsave one.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoalarm: Add a alarm_expired()
Barret Rhoden [Tue, 13 Nov 2018 02:18:57 +0000 (21:18 -0500)]
alarm: Add a alarm_expired()

The rendez code was looking at on_tchain to determine if it had expired
or not.  It is possible for the alarm to have expired even though the
handler hasn't run yet.  If an alarm runs as an RKM, its time might
have come, but it is still on the tchain.  In these cases, we want to
timeout the rendez instead of waiting for the alarm service.

Note that this is safe in regards to the alarm's memory.  I was briefly
worried that we're breaking out of the rendez loop before the alarm
handler runs.  But we do that all the time, such as when a condition
fires, and we handle it by calling unset_alarm().

I noticed this when trying to debug a potential livelock.  We might be
able to go back to on_tchain or something else if that read_tsc() is a
problem.  In that case, we'll just change the helper.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Rename db sem to db blk
Barret Rhoden [Wed, 7 Nov 2018 20:42:40 +0000 (15:42 -0500)]
kth: Rename db sem to db blk

The old "db sem" will keep working for a while.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Clean up sem/cv debugging
Barret Rhoden [Wed, 7 Nov 2018 20:32:43 +0000 (15:32 -0500)]
kth: Clean up sem/cv debugging

The old debug code was specific to semaphores, but it also suffered due
to lock inversion.  The old lock order was list_lock->sem_lock.  That
was to avoid issues when printing.  However, we can just use a trylock.
I might not have had that when I wrote the DB code.  This is more
important now, since cv_wait() is called with the lock already held.

The old DB code also was called regardless of whether or not we blocked.
Instead, we can just track when we actually block - which is *always*
for the CVs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Implement CVs without semaphores
Barret Rhoden [Wed, 7 Nov 2018 16:02:59 +0000 (11:02 -0500)]
kth: Implement CVs without semaphores

Implementing CVs with semaphores was possible, at least when you peer
inside the sem, but it was a minor pain and conflicted with some
upcoming features.

Notably, sem_down() *may* sleep.  cv_wait() *will* sleep.  This makes
the CV code a lot cleaner.

It does break db sem, in the sense that CVs aren't semaphores yet.  I'll
clean that up shortly.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agokth: Break up sem_down()
Barret Rhoden [Wed, 7 Nov 2018 15:57:39 +0000 (10:57 -0500)]
kth: Break up sem_down()

sem_down() is a bit of a beast.  The main purpose here is to split out
the guts of blocking a kthread from the semaphore itself so that we can
make CVs not rely on semaphores.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agoparlib: Fix u32/u64 issue with pvcalarm
Barret Rhoden [Fri, 14 Dec 2018 22:01:30 +0000 (17:01 -0500)]
parlib: Fix u32/u64 issue with pvcalarm

vcore_account_uptime_ticks() returns a u64.  By making it a u32, we'll
eventually make diff 'negative'/'very large' once a vcore's uptime
passes 32 bits, which would break things.

This never popped up, but I noticed it while hunting down other
alarm/time bugs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agofutex: Fix buggy timeout
Barret Rhoden [Fri, 14 Dec 2018 21:49:19 +0000 (16:49 -0500)]
futex: Fix buggy timeout

We were sending the abs_timeout timespec in all cases, even if we
weren't passed a timeout.  That means we were signing up for a timespec
from uninitialized data!  Who knows when that will go off.  If it is far
in the future, we're likely to never notice.  If it happens to go off,
we'll have futexes timing out that shouldn't time out - chaos!

I had a VM that was up long enough that these timers were going off, and
I noticed really old alarms in the "alarm pcpu" output.  They would fire
instantly too.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
22 months agonet: tcp: Don't respond to FIN-less ACKs during TIME-WAIT
Barret Rhoden [Fri, 14 Dec 2018 19:46:50 +0000 (14:46 -0500)]
net: tcp: Don't respond to FIN-less ACKs during TIME-WAIT

Under the normal close sequence, when we receive a FIN|ACK, we enter
TIME-WAIT and respond to that LAST-ACK with an ACK.  Our TCP stack would
send an ACK in response to *any* ACK, which included FIN|ACK but also
included regular ACKs.  (Or PSH|ACKs, which is what we were actually

That was more ACKs than is necessary and results in an endless ACK storm
if we were under the simultaneous close sequence.  In that scenario,
both sides of a connection are in TIME-WAIT.  Both sides receive
FIN|ACK, and both respond with an ACK.  Then both sides receive *those*
ACKs, and respond again.  This continues until the TIME-WAIT wait period
elapses and each side's TCP timers (in the Plan 9 / Akaros case) shut

The fix for this is to only respond to a FIN|ACK when we are in

The way I noticed this was when a Go test simultaneously closed both
ends of a loopback connection.  All of the packets went through the
looback interface and were handled by the loopbackread() ktask.  On
occasion, the tcpackproc() ktask would get scheduled on the same core as
loopbackread(), so the timers would not fire until loopbackread()
yielded (Akaros is non-preemptive).  However, loopbackread() would
always have packets, since for every ACK received, it sent another.
loopbackread() would then receive that packet, since it receives every
packet on both sides of a connection on the loopback interface.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoalarm: Do not allow callbacks to block
Barret Rhoden [Fri, 2 Nov 2018 02:34:17 +0000 (22:34 -0400)]
alarm: Do not allow callbacks to block

This isn't perfect, but it will catch any alarm callbacks that *attempt*
to block.

We have a bunch of issues with alarms.  One of them that affects
userspace, but not the kernel, is alarms that block will delay the
execution of other alarms.  Right now, the kernel just sends kernel
messages, so it's not a big deal.

In upcoming patches, I'm going to need to run all of the alarms in
closer coordination with the tchain so that I can safely tell if unset
works - specifically, the tchain will track which alarm it's running.
To do that, we'll need to serialize alarms on a tchain, which means if
an alarm blocks, it might block all future alarms.  That could deadlock.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoRename RCU CB context to 'cannot block' context
Barret Rhoden [Fri, 2 Nov 2018 02:10:11 +0000 (22:10 -0400)]
Rename RCU CB context to 'cannot block' context

RCU needed to be able to turn on assertions to check if we're blocking
or not.  It's no surprise that we can use that elsewhere, since the
concept is more general than just being an RCU callback.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoalarm: Remove IRQ alarms
Barret Rhoden [Fri, 2 Nov 2018 01:40:45 +0000 (21:40 -0400)]
alarm: Remove IRQ alarms

The alarm code has some issues, and dealing with it will be easier with
only one type of alarm.

Right now, the tchain and the alarm RKMs are disconnected, but I think
we'll need to synchronize them a bit more.  It'll be simpler with just
one mechanism that runs outside of IRQ context.

We only had one user, so remove it isn't a big deal.  If we need IRQ
alarms, we can add them back in the future.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agorendez: Use a regular alarm instead of an IRQ alarm
Barret Rhoden [Fri, 2 Nov 2018 01:27:14 +0000 (21:27 -0400)]
rendez: Use a regular alarm instead of an IRQ alarm

This was the only user of IRQ alarms.  To resolve some issues with
alarms, it'd be easier to not have IRQ alarms at all.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoRemove STAB info
Barret Rhoden [Fri, 2 Nov 2018 01:50:50 +0000 (21:50 -0400)]
Remove STAB info

This was old debugging information.  We haven't used it in years.  All
of our kernel PC-to-name lookups use the reflected symbol table.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoFix assumption of current != NULL
Barret Rhoden [Thu, 25 Oct 2018 13:13:37 +0000 (09:13 -0400)]
Fix assumption of current != NULL

This goes back to the root cause of commit 38346732733e ("Clear current
before calling proc_decref()").  We needed to clear current back when we
abandon_core().  However, the kthread still thought it needed to save
the address space / context of the process and would try to incref a
NULL pointer.

The root issue is that the kthread was a process kthread, but it lost
its connection to the process during the execution of a syscall (or
trap).  The syscall doesn't even need to be the one that did the
killing.  We just needed to be a non-ktask/RKM.

We could also change up the way the kthread flags work, but I wanted to
highlight the existence of this bug.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agoalarm: Force unset_alarm to grab the CV lock
Barret Rhoden [Tue, 16 Oct 2018 14:20:40 +0000 (10:20 -0400)]
alarm: Force unset_alarm to grab the CV lock

The issue here is that unset_alarm() is now used to mean "is the alarm
service done with the alarm."  Previously, it was "has the function run

This all is overly fucked up, due to a bunch of things:
- The alarm callbacks allegedly can block.  Not sure if any of them
  actually need that.
- Unset blocks until a CB is done, meaning it might sleep.
- So we need the CV and flags, and need to do things *after* the
  function pointer runs.
- That means the caller/user needs to be aware of the alarm service, and
  can't reuse/free the alarm right away.
- Alarms can re-arm from within their callbacks, and the service doesn't
  know about it.  Hell, what if they put themselves on another timer

Even with this change, we still have some issues.  Say you set_alarm()
from within a callback.  Then that alarm fires and runs before the alarm
service finishes it's CV work?  This could easily happen with a global
tchain (like parlib provides).  It could also happen with a per-core
timer chain, if the callback calls set_alarm() and then blocks.  Anyway,
under this situation, we could have *two* contexts trying to finish the
same alarm at the same time, where one of them clears is_running while
the other is still running.

Oh, and if an alarm CB blocks, under the current implementation, it'll
block the other unrelated alarms after it.  Not ideal.

The longer term fix might be to not allow alarm CBs to block (in
userspace, this means no uthread mutexes, which is actually already the
case since they run in vcore context).  This actually makes it a lot
more like Linux's timer stuff: they run in softirq context only (not
hard irq), though their del_timer_sync is a bit nasty.  They allow
mod_timer() to be called from within the CB, though maybe a little
discipline could help out with some of the corner cases.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agofutex: Disable notifs when waking waiters
Barret Rhoden [Mon, 15 Oct 2018 20:48:26 +0000 (16:48 -0400)]
futex: Disable notifs when waking waiters

When you call cpu_relax_vc() as a uthread, it simply spins, with the
assumption that we'd find out about the preemption via a
notification/IPI.  Although that is true, parlib will only prioritize
vcore context code.  A 2LS won't know to run particular uthread, since
the "spinning-on" relationship is unknown to the 2LS.

By putting the thread that is the target of the busy-wait in vcore
context (or pretending to, with notifs disabled), we get the behavior we

Note the old version of futex code also had this problem when we
busy-waited on awaiter.data = NULL.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
23 months agofutex: Implement futexes with CVs
Barret Rhoden [Mon, 15 Oct 2018 20:24:50 +0000 (16:24 -0400)]
futex: Implement futexes with CVs

This version is similar to the old one in that we still have a single
futex_element per futex_wait call, and there is a linked list of these
elements.  Future versions could use a hash table or something.

You could even consider having M:1 waiters to addresses, with those
structs in a hash table.  If you do this, consider keeping the futex
elements forever.

The thing to be careful of is the lifetime of the futex element.  This
is something the old code had a hard time with, and this new code is no

The old version had hand-rolled the timeout.  Although the new code
avoids the duplicated issues there, the one benefit of the timeout was
that it yanked 'e' off the list, such that if the futex_wait() uthread
was running, then we knew it was off the list.  In the current version,
we must yank it off the list, and then wait for any users (futex_wake())
to be done with it.  Fun with shared memory synchronization!  The
current approach is similar to the old awaiter.data = NULL approach, but
this is more explicit.

Here are a few other things I considered:
- Put the futex element in the uthread/pthread: our thread could exit,
  instead of just unwinding the stack, so this is broken.  It's still a
use-after-free issue.

- Have a custom timeout with the CV, and have the timeout just do
  futex_wake: Not a bad idea.  I wanted to use the CV infrastructure
instead of rolling our own.  We'd also need a bit to signal that the
wakeup was a timeout.  Also, in future versions, I want to use a single
CV for multiple waiters, and this would break that.

- Never have the waker yank the CV element, just kick the CV: We still
  have the lifetime issues.  Even if we know we didn't timeout, we still
could have another waker (consider multiple threads calling
futex_wake()).  The root cause here is that the waker kicks the CVs
outside the futex lock, which was an attempt to cut down on the number
of locks held across 2LS ops.  Though note the CV lock *is* held across
some 2LS ops (has_blocked).

- Have the waker grab the CV lock while holding the futex lock, in an
  attempt to transfer the lock.  The rule is to hold both locks when
adding/removing an element from the list: That would work, but would
require the waiter to do a trylock (lock ordering), and handling the
fallback (unlock CV, then lock for real).  I'd like to avoid gratuitous
global locking.

- Don't have elements at all, use a single CV: we want to wake based on
  uaddr, which would require knowing the waiters that waited on a
specific addr.  A CV per addr works.  (Right now, we have a CV per

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 years agofutex: Call unset_alarm() before freeing the awaiter
Barret Rhoden [Fri, 12 Oct 2018 15:10:05 +0000 (11:10 -0400)]
futex: Call unset_alarm() before freeing the awaiter

The old 'awaiter->data = NULL' was a signal that we were done with the
awaiter.  The race was that the uthread that called futex_wait() was
restarted before everyone was done with the awaiter - where 'everyone'
means the timeout handler and futex_wake().  The last thing you do to
the awaiter was unblock it.

However, since commit 9969434fee6b ("parlib: Run alarm handlers outside
the tchain lock"), the alarm service is not done with the awaiter until
is_running == false and the condvar is unlocked.  The awaiter->data ==
NULL check was no longer sufficient.

Unsetting the alarm fixes this, just like the CV code does.  Though I
have broader concerns about this and other uses of set_alarm().  In
particular, it's a little lousy to unset alarms you know have completed,
since 'unset' is how you know the alarm is done.

The specific bug was a deadlock.  The alarm service ran the timeout
handler, but didn't grab the CV lock in the awaiter yet.  The uthread
that called futex_wake() unblocked, was run, returned, and then called
other functions (from Go / KenC btw).  That clobbered the awaiter, which
was on the stack.  The VC that ran the alarm handler then tried to grab
the CV lock, which happened to be clobbered with a function return
address.  The actual clobber was to set the lock 0, which meant that VC
0 was the lockholder.  VC 1 would just spin, checking that VC 0 was not

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 years agoalarm: Clean up condition variable usage
Barret Rhoden [Thu, 11 Oct 2018 20:33:14 +0000 (16:33 -0400)]
alarm: Clean up condition variable usage

The while loop is the classic Mesa-semantic use of a CV.  For some
reason, the old version was a tortured while loop with breaks and
whatnot.  The new version is simpler, easier to read, classically
correct, and has a nicer personality.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 years agonet: Clear stale synth_buf pointer
Barret Rhoden [Thu, 11 Oct 2018 20:30:49 +0000 (16:30 -0400)]
net: Clear stale synth_buf pointer

No one should use synth_buf that did not set it, but this prevents
reusing the pointer.  Or at least it prevents reusing a non-NULL
pointer.  =)

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>