Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ATF t_mlock() babylon5 kernel panics
Some progress.
#1 touching the buffer that malloc() returns (which is page aligned)
made no difference - it is likely that the malloc llibrary would have
done that in any case (the malloc is for just one page, so either it
is resident (or paged) or it is a ZFoD page, and most likely not the
latter - certainly not after this small mod.)
#2 changing the mlock_clip to avoid the sequence
mlock(buf, 0);
munlock(buf, 0);
avoided all of the issues and problems, and the test passed.
What locking 0 bytes might achieve I have no idea, but that is
what the test does:
buf = malloc(page);
/*...*/
for (size_t i = page; i >= 1; i = i - 1024) {
err1 = mlock(buf, page - i);
if (err1 != 0)
fprintf(stderr, "mlock_clip: page=%ld i=%zu,"
" mlock(%p, %ld): %s\n", page, i, buf, page - i,
strerror(errno));
err2 = munlock(buf, page - i);
/*...*/
That first munlock() is where the panic (with the extra KASSERTs added)
occurs.
The err1 = and err2 = are recent additions so that printf (and a
similar one after the munlock) can indicate if anything goes wrong.
The mlock(buf, 0) (first time around the loop when page == i)
call did not fail (err1 == 0). Or at least it seemed to be OK
(there was no output, but there might have been some coming when
the munlock() caused the panic i I will try again (much much
later today) with a sleep between mlock() and munlock() so any
output has time to drain.
Anyway, this might give someone enough of a clue as to what is happening
that that someone (who understands UVM and the pmap code) can fix things.
There's no indication in the mlock() man page, or in the posix spec,
that len == 0 is anything but a valid call (one would expect it to be
a no-op though, rather than scrambling the kernel data structs).
With that loop modified so i starts at page - 1024 everything is fine,
kre
Home |
Main Index |
Thread Index |
Old Index