Skip to content
Snippets Groups Projects
  1. Dec 11, 2013
    • Glauber Costa's avatar
      mmu: fix allocate_intermediate_level · 3e6763f7
      Glauber Costa authored
      
      We have recently seen a problems where eventual page fault outside
      application would occur.
      
      I managed to track that down to my huge page failure patch, but wasn't
      really sure what was going on. Kudos for Raphael, then,  that figured
      out that the problem happened when allocate_intemediate_level was called
      from split_huge_page.
      
      The problem here, is that in that case we do *not* enter
      allocate_intermediate_level with the pte emptied, and were previously
      expecting the write of the new pte to happen unconditionally. The
      compare_exchange broke it, because the exchange doesn't really happen.
      
      There are many ways to fix this issue, but the least confusing of them,
      given that there are other callers to this function that could
      potentially display this problem, is to do some deffensive programming
      and clearly separate the semantics of both types of callers.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Tested-by: default avatarRaphael S. Carvalho <raphaelsc@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      3e6763f7
    • Nadav Har'El's avatar
      Verify slow page fault only happens when preemption is allowed · b7620ca2
      Nadav Har'El authored
      
      Once page_fault() checks that this is not a fast fixup (see safe_load()),
      we reach the page-fault slow path, which needs to allocate memory or
      even read from disk, and might sleep.
      
      If we ever get such a slow page-fault inside kernel code which has
      preemption or interrupts disabled, this is a serious bug, because the
      code in question thinks it cannot sleep. So this patch adds two
      assertions to verify this.
      
      The preemptable() assertion is easily triggered if stacks are demand-paged
      as explained in commit 41efdc1c (I have
      a patch to solve this, but it won't fit in the margin).
      However, I've also seen this assertion without demand-paged stacks, when
      running all tests together through testrunner.so. So I'm hoping these
      assertions will be helpful in hunting down some elusive bugs we still have.
      
      This patch adds a third use of the "0x200" constant (the nineth bit of
      the rflags register is the interrupt flag), so it replaces them by a
      new symbolic name, processor::rflags_if.
      
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      b7620ca2
    • Glauber Costa's avatar
      vma_fault: propagate exception frame to fault handlers · 7ab5f9e8
      Glauber Costa authored
      
      We suddenly stop propagating the exception frame down the vma_fault path.
      There is no reason not to propagate it further, aside from the fact that
      currently there are no users. However, aside from the fact that it presents a
      more consistent frame passing, I intend to use it for the JVM balloon.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      7ab5f9e8
    • Raphael S. Carvalho's avatar
    • Nadav Har'El's avatar
      Rename blacklisted tests · 4e4e191f
      Nadav Har'El authored
      
      Rename blacklisted tests, from tst-wake.cc et al. to misc-wake.cc.
      
      The different name will cause these tests not to be automatically run
      by "make check" - without needing the separate blacklist in test.py
      (which this patch deletes).
      After this patch, testrunner.so will also only run tests called tst-*,
      so will not run the misc-* tests.
      
      The misc-* tests can still be run manually, e.g.,
        run.py -e tests/misc-mutex.so
      
      In addition to the previously blacklisted tests, this patch "blacklists"
      (renames) a few additional tests which fail quickly, but test.py didn't
      know because they didn't use the word "fail". An example is tst-schedule.so,
      which existed immediately when not run on 1 vcpu. So this patch also
      renames it to misc-schedule.so, so "make check" or testrunner.so won't
      run this test.
      
      Note that after this patch, testrunner.so is a new way to run all tests,
      but it isn't working well yet because it still exposes new bugs that do not
      exist in the separate tests (depending on your view point, this might be
      considered a feature, not a bug, in testrunner.so...).
      
      Signed-off-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      4e4e191f
    • Asias He's avatar
      virtio-blk: Disable interrupts while irq handling is in progress · 8cc46dca
      Asias He authored
      
      This reduces unnecessary interrupts that host could send to guest
      while guest is in the progress of irq handling.
      
      In virtio_driver::wait_for_queue, we will re-enable interrupts when
      there is nothing to process.
      
      Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      8cc46dca
    • Pekka Enberg's avatar
      tst-fs-link.so: Use mktemp() for path names · df4a7bd2
      Pekka Enberg authored
      
      Using hard-coded path names is problematic because other test cases may
      use the same path names and forget to clean up after them.
      
      Make tst-fs-link.so more robust by using mktemp() to generate unique
      path names.
      
      Reviewed-by: default avatarTomasz Grabiec <tgrabiec@gmail.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      df4a7bd2
    • Glauber Costa's avatar
      tests: fix threads being destroyed earlier. · b0dc3f1a
      Glauber Costa authored
      
      The last part of the standard thread tests created 4 threads and calls the
      detach of one from the body of the other. They live in the same block to
      guarantee that they will all be destroyed more or less at the same time (we
      expect). Avi, however, demonstrated that a mistake prevents that from being
      the actual case:
      
          t1 starts to run
          t2 starts to run
          t3 starts to run
          t4 starts to run
          t4 is detached
          t4 is destroyed (ok)
          t3 is destroyed. wasn't detached or join, to terminate
          t1, t2, t3 are detached, but too late
      
      This introduces a simple wait mechanism to avoid having the threads
      terminated after the block is gone.
      
      Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
      Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      b0dc3f1a
  2. Dec 10, 2013
  3. Dec 09, 2013
Loading