next& wait until
sysctl machdep.cpu | grep features
sde -tsx -- ./a.out 4
->locked = 0in
Make sure you understand what would happen if the kernel executed the following code snippet:
Feel free to use QEMU to find out;
acquire is in
acquire ensures interrupts are off on the local processor using
cli instruction (via
pushcli()), and interrupts remain off until
the release of the last lock held by that processor (at which point
they are enabled using
Let’s see what happens if we turn on interrupts while holding the
ide lock. In
ide.c, add a call to
sti() after the
acquire(), and a call to
cli() just before the
Rebuild the kernel and boot it in QEMU. Chances are the kernel will
panic soon after boot; try booting QEMU a few times if it doesn’t.
Try running QEMU on Linux.
Make sure you understand why the kernel panicked. You may find it
useful to look up the stack trace (the sequence of
printed by panic) in the
cli() you added, rebuild the kernel, and make sure it works again.
Now let’s see what happens if we turn on interrupts while holding
ftable.lock. This lock protects the table of file descriptors,
which the kernel modifies when an application opens or closes a
file.c, add a call to
sti() after the call
acquire(), and a
cli() just before each of the
will also need to add
#include "x86.h" at the top of the file after
#include lines. Rebuild the kernel and boot it in QEMU.
It will not panic.
Why didn’t the kernel panic?
ide_lock have different behavior in this respect?
You do not need to understand anything about the details of the IDE hardware to answer this question, but you may find it helpful to look at which functions acquire each lock, and then at when those functions get called.
There is a very small but non-zero chance that the kernel will panic
with the extra
filealloc(). If the kernel does panic, make
doubly sure that you removed the
sti() call from
lk->cpu before clearing
lk->locked? Why not wait until after?