1. 03 Mar, 2021 1 commit
  2. 02 Mar, 2021 1 commit
  3. 27 Feb, 2021 1 commit
    • 4lDO2's avatar
      Fix "Grant should not exist" errors. · 031496ff
      4lDO2 authored
      This is done by making sure that when empty() is called on a context,
      the grants Arc will be replaced with a new unused Arc, hence
      decrementing the refcount. Previously this was only done when the
      context was actually reaped, but since there is no guarantee as far as I
      am aware about when this must happen, the grants could be completely
      leaked, leading to the error.
  4. 23 Feb, 2021 2 commits
  5. 20 Feb, 2021 1 commit
    • 4lDO2's avatar
      Give schemes a dangling address for empty slices. · ad58ca1d
      4lDO2 authored
      This allows schemes to avoid checking the length against zero before
      constructing a slice from pointer+len that the kernel gave.
      Additionally, the address is now non-canonical on x86, meaning that
      userspace will fail instead of continuing with UB, if they would ever
      forget to check the length.
  6. 17 Feb, 2021 3 commits
    • 4lDO2's avatar
      Use GS for TLS! · bdc925d2
      4lDO2 authored
      Previously, the kernel used the regular FS segment for Thread-Local
      Storage. The problem however, is that userspace code also uses FS for
      TLS, meaning that the kernel would have to switch the FS segment between
      user and kernel, _upon every syscall_. This is obviously suboptimal for
      performance (especially with fast syscalls such as futex, nanosleep, or
      I had to search LLVM for hours, just to find out that the insertion of
      the memory load with FS was actually done in the linker, so I added a
      flag for that.
      I haven't done any proper benchmarking, but the boot process seems to
      have gotten much faster!
    • Jeremy Soller's avatar
      Merge branch 'sysretq-fix2' into 'master' · a283160c
      Jeremy Soller authored
      FIX: Forbid lower-half noncanonical addresses too.
      See merge request !170
    • 4lDO2's avatar
      Forbid lower-half noncanonical addresses too. · 1988583e
      4lDO2 authored
  7. 15 Feb, 2021 14 commits
  8. 14 Feb, 2021 1 commit
  9. 13 Feb, 2021 12 commits
  10. 03 Feb, 2021 3 commits
    • 4lDO2's avatar
      Make cpu_id_opt non-mutable. · 6f3fc3a4
      4lDO2 authored
    • 4lDO2's avatar
      Fix a very annoying multi_core data race*. · 44527a83
      4lDO2 authored
      So, when I first introduced io_uring, it was not compiled with the
      `multi_core` kernel feature, mainly to make development easier (I
      thought). However, since io_uring allows multiple simultaneous system
      calls, we cannot longer make the in-kernel contexts block, for example
      when receiving a message from a pipe, if there can be multiple such
      requests simultaneously.
      This has required me to change WaitCondition into allowing multiple
      simultaneous tasks; although, it introduces a potential race condition:
      since a future can only return Pending and not block directly before
      releasing the lock (condvar logic), we need some way to make sure that
      nothing happens after the context finds out that it has to wait, and the
      actual waiting. If a message is pushed in between, and the waker is
      called (Context::unblock), just before it was going to block itself,
      then we miss the message, and potentially cause a deadlock.
      Fortunately, in order to block and unblock contexts, we need to
      exclusively lock the context. So, what we can do to ensure that waking
      while running is no longer a no-op, is to introduce a "wake flag", which
      is set only if the context is currently running, and Runnable.
      But, this still caused all weird kinds of hard-to-debug problems, with
      arbitrary CPU exceptions and possibly memory corruption. The reason for
      this, is that the context switching logic uses really unsafe operations,
      which is why context switching (at the moment) requires an exclusive
      lock. Before this commit, it would modify the `running` field after the
      lock had been released, which obviously can cause a data race, when the
      regular context waker code that is run within a system call, locks the
      context but not the global switching lock.
      The solution was to make sure that the locks were held, all the way
      until the actual switching, which was done in assembly. There can still
      be a race condition here, since it modifies memory containing registers
      after the lock has been released, even if it may be behind &mut on
      another context, which can be UB, but it has not contributed to any
      actual bugs... yet.
      * I have not yet done that rigorous testing, but it appears to work well
      enough, and I have not encountered the bug after like 10 tries.
    • 4lDO2's avatar
      Use physical addresses internally for futexes. · fec8f4aa
      4lDO2 authored
      This solves a bug, that allows processes in different address spaces to
      be the target of a futex wakeup call, even though that process is in
      another address space!
  11. 13 Jan, 2021 1 commit