Commit graph

72 commits

Author SHA1 Message Date
Robert Morris ebc3937209 conservatively call sfence.vma before every satp load. 2019-07-16 17:02:21 -04:00
Robert Morris 4bc900e78b nits 2019-07-10 14:54:34 -04:00
Robert Morris 061e3be6f8 more comment cleanup 2019-07-10 10:13:08 -04:00
Robert Morris 5eb1685700 have kill() lock before looking at p->pid
document wait()'s use of np->parent w/o holding lock.
2019-07-10 09:24:50 -04:00
Robert Morris 9981bb2270 tweak some comments. 2019-07-10 08:57:51 -04:00
Robert Morris 9d34838b4f holding p->lock all the way through state=RUNNABLE means we don't need EMBRYO 2019-07-08 11:11:00 -04:00
Robert Morris db72f3108f eliminate ptable. ptable.lock -> pid_lock. 2019-07-07 15:20:13 -04:00
Robert Morris 4ce3a5fa21 nits 2019-07-07 14:57:16 -04:00
Robert Morris c4f6a241cd avoid a double-lock of initproc->lock if child of init is reparenting 2019-07-07 07:03:28 -04:00
Frans Kaashoek dabbc348bc Maybe fix two races identified by rtm (thx!):
- during exit(), hold p's parent lock and p's lock across all changes
to p and its parent (e.g., reparenting and wakeup1).  the lock
ordering between concurrent exits of children, parent, and great
parent might work out because processes form a tree.

- in wakeup1() test and set p->state atomically by asking caller to
have p locked.

a correctness proof would be desirable.
2019-07-06 16:38:41 -04:00
Frans Kaashoek 6bfb078b14 x 2019-07-04 08:54:16 -04:00
Frans Kaashoek 47e69250d0 Simplify wakeup1 2019-07-03 15:38:30 -04:00
Frans Kaashoek cee830af24 Apply some corresponding bug fixes from wq branch here 2019-07-03 15:18:55 -04:00
Frans Kaashoek 26f306113a Fix a lost wakeup bug: the disk driver's wakeup() can run after the
reading process acquired p->lock and released virtio lock in sleep(),
but before the process had set p->status to SLEEPING, because the
wakeup tested p->status without holding p's lock.  Thus, wakeup can
complete without seeing any process SLEEPING and then p sets p->status
to SLEEPING.

Fix some other issues:

- Don't initialize proc lock in allocproc(), because freeproc() sets
np->state = UNUSED and allocproc() can choose np and calls initlock()
on the process's lock, releasing np's lock accidentally.  Move
initializing proc's lock to init.

- Protect nextpid using ptable.lock (and move into its own function)

Some clean up:
- Don't acquire p->lock when it p is used in a private way (e.g., exit()/grow()).
- Move find_runnable() back into scheduler().
2019-07-02 19:29:14 -04:00
Frans Kaashoek 1e4d7065d6 Merge branch 'riscv' into riscv-proc 2019-07-02 14:19:31 -04:00
Frans Kaashoek 84c759fc02 x 2019-07-02 14:09:38 -04:00
Frans Kaashoek 37ac6f8f4f Don't start processes at the end of the proc table 2019-07-02 13:55:52 -04:00
Frans Kaashoek da51735980 Avoid two cores selecting the same process to run 2019-07-02 13:40:33 -04:00
Robert Morris b27f275014 avoid allocproc() returning a struct proc with non-zero p->sz 2019-07-02 11:17:50 -04:00
Frans Kaashoek 67702cf706 Checkpoint switching to per-process locks, in attempt clarify xv6's
locking plan, which is a difficult to understand because ptable lock
protects many invariants.  This implementation has a bug: once in a
while xv6 unlocks a proc lock that is locked by another core.
2019-07-02 09:14:47 -04:00
Robert Morris abfe9999f4 have fork() fail, not panic, if not enough phys mem 2019-07-01 17:46:06 -04:00
Robert Morris 5753553213 separate source into kernel/ user/ mkfs/ 2019-06-11 09:57:14 -04:00
Renamed from proc.c (Browse further)