| Age | Commit message (Collapse) | Author | Files | Lines | |
|---|---|---|---|---|---|
| 2019-07-10 | nits | Robert Morris | 1 | -1/+3 | |
| 2019-07-10 | more comment cleanup | Robert Morris | 1 | -24/+30 | |
| 2019-07-10 | have kill() lock before looking at p->pid | Robert Morris | 1 | -22/+27 | |
| document wait()'s use of np->parent w/o holding lock. | |||||
| 2019-07-10 | tweak some comments. | Robert Morris | 1 | -12/+8 | |
| 2019-07-08 | holding p->lock all the way through state=RUNNABLE means we don't need EMBRYO | Robert Morris | 1 | -11/+6 | |
| 2019-07-07 | eliminate ptable. ptable.lock -> pid_lock. | Robert Morris | 1 | -15/+14 | |
| 2019-07-07 | nits | Robert Morris | 1 | -10/+11 | |
| 2019-07-07 | avoid a double-lock of initproc->lock if child of init is reparenting | Robert Morris | 1 | -2/+5 | |
| 2019-07-06 | Maybe fix two races identified by rtm (thx!): | Frans Kaashoek | 1 | -12/+20 | |
| - 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-04 | x | Frans Kaashoek | 1 | -1/+1 | |
| 2019-07-03 | Simplify wakeup1 | Frans Kaashoek | 1 | -11/+5 | |
| 2019-07-03 | Apply some corresponding bug fixes from wq branch here | Frans Kaashoek | 1 | -27/+25 | |
| 2019-07-02 | Fix a lost wakeup bug: the disk driver's wakeup() can run after the | Frans Kaashoek | 1 | -65/+50 | |
| 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 | Merge branch 'riscv' into riscv-proc | Frans Kaashoek | 1 | -13/+31 | |
| 2019-07-02 | x | Frans Kaashoek | 1 | -1/+1 | |
| 2019-07-02 | Don't start processes at the end of the proc table | Frans Kaashoek | 1 | -6/+8 | |
| 2019-07-02 | Avoid two cores selecting the same process to run | Frans Kaashoek | 1 | -26/+33 | |
| 2019-07-02 | avoid allocproc() returning a struct proc with non-zero p->sz | Robert Morris | 1 | -0/+2 | |
| 2019-07-02 | Checkpoint switching to per-process locks, in attempt clarify xv6's | Frans Kaashoek | 1 | -69/+113 | |
| 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-01 | have fork() fail, not panic, if not enough phys mem | Robert Morris | 1 | -13/+29 | |
| 2019-06-11 | separate source into kernel/ user/ mkfs/ | Robert Morris | 1 | -0/+591 | |
 |
index : 135e2/xv6-labs.git | |
| xv6-labs-2024-winter | 135e2 |
| summaryrefslogtreecommitdiff |