Commit graph

478 commits

Author SHA1 Message Date
rsc
4f74de0edc okay, that was long enough - revert 2007-09-27 20:32:45 +00:00
rsc
ce2e751555 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.
2007-09-27 20:29:50 +00:00
rsc
aefc13f8ba nit 2007-09-27 20:25:32 +00:00
rsc
3807c1f20b rename splhi/spllo to pushcli/popcli 2007-09-27 20:09:40 +00:00
rsc
39c3fb1b15 overkill: use segments to catch stack overflow (delete before next year) 2007-09-27 19:39:10 +00:00
rsc
8c8b748a2f now spllo is okay 2007-09-27 19:35:25 +00:00
rsc
b5dcebdbeb better lapic writes, suggested by cliff 2007-09-27 19:33:46 +00:00
rsc
4721271961 use larger, allocated cpu stacks 2007-09-27 19:32:43 +00:00
rsc
0fe118f3f6 don't call it ss - that's the stack segment 2007-09-27 16:47:50 +00:00
rsc
c8919e6537 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.
2007-09-27 12:58:42 +00:00
rsc
75506c6655 use console lock 2007-09-27 12:29:25 +00:00
rsc
d522571068 make slow bigdir last test 2007-09-27 12:29:06 +00:00
rsc
ad12b487b5 changes since two days ago:
drop , address=0xf0000 from romimage line.
newer bochs has a 128k bios that it loads elsewhere.
so let bochs decide where the romimage goes.

change cpu quantum to 1 (default is 5, max is 16)
in an attempt to provoke more races.  only provokes
them slightly more frequently, may not be worth
the slowdown.
2007-09-27 11:27:04 +00:00
rsc
b30ab3f5af use standard bios location 2007-09-27 05:14:25 +00:00
rsc
666f58c711 believe it or not, this was working
the macro expansion of "char *cp;" turned into
char *(curproc[cpu()]);  which declares a dynamically
sized array of char* called curproc.

so then &cp == &(curproc[cpu()]) was actually a
stack variable as "expected".  it was one past the
end of the array, but the implicit alloca allocated
more than was necessary.

do not tell me that making cp a #define was a bad idea.
there are worse problems to fix.  more on that later.
2007-09-27 05:13:10 +00:00
rsc
90d975e9c8 comment bochs nonsense 2007-09-26 23:32:47 +00:00
rsc
fbaa7b428e various comment and print tweaks 2007-09-26 23:32:00 +00:00
rsc
56c1a151d2 debugging prints 2007-09-26 23:24:23 +00:00
rsc
d5596cd61d Apparently the initial interrupt count lapic[TICR]
must be set *after* initializing the lapic[TIMER] vector.

Doing this, we now get clock interrupts on cpu 1.
(No idea why we always got them on cpu 0.)

Don't write to TCCR - it is read-only.
2007-09-26 20:34:12 +00:00
rtm
355073ea9e oops, interrupts on in syscall traps doesn't work after all 2007-09-25 16:15:05 +00:00
rtm
3eda2714e6 tell SETGATE to leave interrupts on for T_SYSCALL
panic if unknown fault with CPL=0 (i.e. in kernel)
2007-09-25 15:23:44 +00:00
nelhage
d7a90d3b5c This should fix building on FreeBSD 2007-09-19 23:49:52 +00:00
nelhage
6197c04208 Fix compilation on 64-bit machines (thanks to andersk for patch) 2007-09-18 00:41:34 +00:00
rtm
411ee74127 fix comments 2007-09-15 20:05:47 +00:00
rsc
e9f8419fbe sh 2007-09-05 15:55:43 +00:00
rtm
ab4cedb593 continuous quality management 2007-08-31 19:55:27 +00:00
rsc
ef2185247d symlink implementation 2007-08-30 18:36:38 +00:00
rsc
e51ae8a272 do not toss .ps 2007-08-30 18:33:48 +00:00
rsc
9863fea78c clumsy cd 2007-08-30 18:30:26 +00:00
rtm
fbd8857d4d make new Homework 8 work 2007-08-30 18:21:35 +00:00
rsc
37321196a4 oops - broke circular buffer 2007-08-30 18:20:53 +00:00
rsc
71d5bf4d08 oops - broke arg counting 2007-08-30 18:19:52 +00:00
rtm
de1329dda2 longjmp -> swtch in comments 2007-08-30 17:39:56 +00:00
rsc
05109382d6 tweak 2007-08-30 14:12:19 +00:00
rsc
42f3c3f7be DO NOT MAIL: xv6-rev1 2007-08-30 14:11:21 +00:00
rsc
55401f2adb final xv6 for 2007 2007-08-30 14:09:14 +00:00
rsc
febdc07c35 bootothers now in main 2007-08-29 19:20:49 +00:00
rtm
bc54fa3915 spelling 2007-08-29 18:18:57 +00:00
rsc
bf2932a686 final nits 2007-08-28 19:39:49 +00:00
rsc
68a2d5373d match README 2007-08-28 19:30:29 +00:00
rsc
f040060092 nits 2007-08-28 19:30:23 +00:00
rsc
cffa954301 nits 2007-08-28 19:25:04 +00:00
rsc
5573c8f296 delete proc_ on proc_exit, proc_wait, proc_kill 2007-08-28 19:14:43 +00:00
rsc
eb52c7de1d comments; rename irq_ to pic_ 2007-08-28 19:04:36 +00:00
rsc
5516be1fed spaces around else for rtm 2007-08-28 18:37:41 +00:00
rsc
e4d6a21165 more consistent spacing 2007-08-28 18:32:08 +00:00
rsc
c1b100e930 nits 2007-08-28 18:23:48 +00:00
rsc
3e1eaf226d fix offsets 2007-08-28 18:04:43 +00:00
rsc
a491dba00c more cmain -> bootmain 2007-08-28 18:02:49 +00:00
rsc
d844f0f9d9 Change dev read/write functions
to take inode* instead of minor number.

Unlock console inode during console_read
and console_write.  Otherwise background
processes cannot write to console while the
shell is reading it waiting for input.
2007-08-28 17:49:49 +00:00