Skip to content
Snippets Groups Projects
  1. Sep 11, 2008
  2. Sep 09, 2008
  3. Sep 03, 2008
  4. Aug 28, 2008
  5. Aug 22, 2008
  6. Aug 21, 2008
  7. Aug 20, 2008
  8. Dec 20, 2007
  9. Nov 28, 2007
    • rsc's avatar
      fork minibug · c2258bf4
      rsc authored
      c2258bf4
    • rsc's avatar
      More complete lapic startup (thanks Silas) · 4f06ae0d
      rsc authored
      4f06ae0d
    • rsc's avatar
      · a6c4711a
      rsc authored
      bda[0xE] is a 16-bit segment number,
      not a real address.  So shift 4.
      
      Reported by Silas.
      
      Jim McKie says this code only matters
      on ancient EISA MP systems.
      a6c4711a
  10. Oct 20, 2007
  11. Oct 12, 2007
    • rsc's avatar
      · 949352af
      rsc authored
      Model verifying that wakeup really
      can be called after release without
      causing deadlock.
      949352af
  12. Oct 01, 2007
    • rsc's avatar
      · 943fd378
      rsc authored
      Incorporate new understanding of/with Intel SMP spec.
      
      Dropped cmpxchg in favor of xchg, to match lecture notes.
      
      Use xchg to release lock, for future protection and to
      keep gcc from acting clever.
      943fd378
  13. Sep 30, 2007
    • rsc's avatar
      · 9fd9f804
      rsc authored
      Re: why cpuid() in locking code?
      
      rtm wrote:
      > Why does acquire() call cpuid()? Why does release() call cpuid()?
      
      The cpuid in acquire is redundant with the cmpxchg, as you said.
      I have removed the cpuid from acquire.
      
      The cpuid in release is actually doing something important,
      but not on the hardware.  It keeps gcc from reordering the
      lock->locked assignment above the other two during optimization.
      (Not that current gcc -O2 would choose to do that, but it is allowed to.)
      I have replaced the cpuid in release with a "gcc barrier" that
      keeps gcc from moving things around but has no hardware effect.
      
      On a related note, I don't think the cpuid in mpmain is necessary,
      for the same reason that the cpuid wasn't needed in release.
      
      As to the question of whether
      
        acquire();
        x = protected;
        release();
      
      might read protected after release(), I still haven't convinced
      myself whether it can.  I'll put the cpuid back into release if
      we determine that it can.
      
      Russ
      9fd9f804
    • rsc's avatar
      tricks · c840f3ec
      rsc authored
      c840f3ec
  14. Sep 27, 2007
    • rsc's avatar
      · af7366c9
      rsc authored
      interrupts during system calls
      
      "It just works."
      af7366c9
    • rsc's avatar
      · ab08960f
      rsc authored
      Final word on the locking fiasco?
      
      Change pushcli / popcli so that they can never turn on
      interrupts unexpectedly.  That is, if interrupts are on,
      then pushcli(); popcli(); turns them off and back on, but
      if they are off to begin with, then pushcli(); popcli(); is
      a no-op.
      
      I think our fundamental mistake was having a primitive
      (release and then popcli nee spllo) that could turn
      interrupts on at unexpected moments instead of being
      explicit about when we want to start allowing interrupts.
      
      With the new semantics, all the manual fiddling of ncli
      to force interrupts off in certain sections goes away.
      In return, we must explicitly mark the places where
      we want to enable interrupts unconditionally, by calling sti().
      There is only one: inside the scheduler loop.
      ab08960f
    • rsc's avatar
      cleaner · f97f0d2b
      rsc authored
      f97f0d2b
    • rsc's avatar
      yank out stack overflow checking ugliness · c95bde81
      rsc authored
      c95bde81
    • rsc's avatar
      okay, that was long enough - revert · 4f74de0e
      rsc authored
      4f74de0e
    • rsc's avatar
      · ce2e7515
      rsc authored
      test: store curproc at top of stack
      
      I don't actually think this is worthwhile, but I figured
      I would check it in before reverting it, so that it can
      be in the revision history.
      
      Pros:
        * curproc doesn't need to turn on/off interrupts
        * scheduler doesn't have to edit curproc anymore
      
      Cons:
        * it's ugly
        * all the stack computation is more complicated.
        * it doesn't actually simplify anything but curproc,
          and even curproc is harder to follow.
      ce2e7515
    • rsc's avatar
      nit · aefc13f8
      rsc authored
      aefc13f8
    • rsc's avatar
      rename splhi/spllo to pushcli/popcli · 3807c1f2
      rsc authored
      3807c1f2
    • rsc's avatar
    • rsc's avatar
      now spllo is okay · 8c8b748a
      rsc authored
      8c8b748a
    • rsc's avatar
      better lapic writes, suggested by cliff · b5dcebdb
      rsc authored
      b5dcebdb
    • rsc's avatar
      use larger, allocated cpu stacks · 47212719
      rsc authored
      47212719
    • rsc's avatar
      don't call it ss - that's the stack segment · 0fe118f3
      rsc authored
      0fe118f3
    • rsc's avatar
      · c8919e65
      rsc authored
      kernel SMP interruptibility fixes.
      
      Last year, right before I sent xv6 to the printer, I changed the
      SETGATE calls so that interrupts would be disabled on entry to
      interrupt handlers, and I added the nlock++ / nlock-- in trap()
      so that interrupts would stay disabled while the hw handlers
      (but not the syscall handler) did their work.  I did this because
      the kernel was otherwise causing Bochs to triple-fault in SMP
      mode, and time was short.
      
      Robert observed yesterday that something was keeping the SMP
      preemption user test from working.  It turned out that when I
      simplified the lapic code I swapped the order of two register
      writes that I didn't realize were order dependent.  I fixed that
      and then since I had everything paged in kept going and tried
      to figure out why you can't leave interrupts on during interrupt
      handlers.  There are a few issues.
      
      First, there must be some way to keep interrupts from "stacking
      up" and overflowing the stack.  Keeping interrupts off the whole
      time solves this problem -- even if the clock tick handler runs
      long enough that the next clock tick is waiting when it finishes,
      keeping interrupts off means that the handler runs all the way
      through the "iret" before the next handler begins.  This is not
      really a problem unless you are putting too many prints in trap
      -- if the OS is doing its job right, the handlers should run
      quickly and not stack up.
      
      Second, if xv6 had page faults, then it would be important to
      keep interrupts disabled between the start of the interrupt and
      the time that cr2 was read, to avoid a scenario like:
      
         p1 page faults [cr2 set to faulting address]
         p1 starts executing trapasm.S
         clock interrupt, p1 preempted, p2 starts executing
         p2 page faults [cr2 set to another faulting address]
         p2 starts, finishes fault handler
         p1 rescheduled, reads cr2, sees wrong fault address
      
      Alternately p1 could be rescheduled on the other cpu, in which
      case it would still see the wrong cr2.  That said, I think cr2
      is the only interrupt state that isn't pushed onto the interrupt
      stack atomically at fault time, and xv6 doesn't care.  (This isn't
      entirely hypothetical -- I debugged this problem on Plan 9.)
      
      Third, and this is the big one, it is not safe to call cpu()
      unless interrupts are disabled.  If interrupts are enabled then
      there is no guarantee that, between the time cpu() looks up the
      cpu id and the time that it the result gets used, the process
      has not been rescheduled to the other cpu.  For example, the
      very commonly-used expression curproc[cpu()] (aka the macro cp)
      can end up referring to the wrong proc: the code stores the
      result of cpu() in %eax, gets rescheduled to the other cpu at
      just the wrong instant, and then reads curproc[%eax].
      
      We use curproc[cpu()] to get the current process a LOT.  In that
      particular case, if we arranged for the current curproc entry
      to be addressed by %fs:0 and just use a different %fs on each
      CPU, then we could safely get at curproc even with interrupts
      disabled, since the read of %fs would be atomic with the read
      of %fs:0.  Alternately, we could have a curproc() function that
      disables interrupts while computing curproc[cpu()].  I've done
      that last one.
      
      Even in the current kernel, with interrupts off on entry to trap,
      interrupts are enabled inside release if there are no locks held.
      Also, the scheduler's idle loop must be interruptible at times
      so that the clock and disk interrupts (which might make processes
      runnable) can be handled.
      
      In addition to the rampant use of curproc[cpu()], this little
      snippet from acquire is wrong on smp:
      
        if(cpus[cpu()].nlock == 0)
          cli();
        cpus[cpu()].nlock++;
      
      because if interrupts are off then we might call cpu(), get
      rescheduled to a different cpu, look at cpus[oldcpu].nlock, and
      wrongly decide not to disable interrupts on the new cpu.  The
      fix is to always call cli().  But this is wrong too:
      
        if(holding(lock))
          panic("acquire");
        cli();
        cpus[cpu()].nlock++;
      
      because holding looks at cpu().  The fix is:
      
        cli();
        if(holding(lock))
          panic("acquire");
        cpus[cpu()].nlock++;
      
      I've done that, and I changed cpu() to complain the first time
      it gets called with interrupts disabled.  (It gets called too
      much to complain every time.)
      
      I added new functions splhi and spllo that are like acquire and
      release but without the locking:
      
        void
        splhi(void)
        {
          cli();
          cpus[cpu()].nsplhi++;
        }
      
        void
        spllo(void)
        {
          if(--cpus[cpu()].nsplhi == 0)
            sti();
        }
      
      and I've used those to protect other sections of code that refer
      to cpu() when interrupts would otherwise be disabled (basically
      just curproc and setupsegs).  I also use them in acquire/release
      and got rid of nlock.
      
      I'm not thrilled with the names, but I think the concept -- a
      counted cli/sti -- is sound.  Having them also replaces the
      nlock++/nlock-- in trap.c and main.c, which is nice.
      
      
      Final note: it's still not safe to enable interrupts in
      the middle of trap() between lapic_eoi and returning
      to user space.  I don't understand why, but we get a
      fault on pop %es because 0x10 is a bad segment
      descriptor (!) and then the fault faults trying to go into
      a new interrupt because 0x8 is a bad segment descriptor too!
      Triple fault.  I haven't debugged this yet.
      c8919e65
Loading