Comments inline...
Dag-Erling Smørgrav wrote:
Lawrence Stewart <[EMAIL PROTECTED]> writes:
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
I don't know how to use them really. Thus far I haven't had a need for
really low level debugging tools... seems that may have changed
though! Any good tutorials/pointers on how to get started with kernel
debugging?
The handbook and FAQ have information on debugging panics. Greg Lehey
(grog@) does a tutorial on kernel debugging, you can probably find
slides online (or just ask him)
For reference, I found what looks to be a very comprehensive kernel
debugging reference here:
http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf
Greg certainly knows the ins and outs of kernel debugging!
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
So this is where my knowledge/understanding gets very hazy...
When a thread blocks waiting for some operation to complete or event
to happen, the thread effectively goes to sleep, correct?
It depends on the type of lock used, but mostly, yes.
Looking at the kio_write code in subr_kernio.c, I'm guessing the lock
that is causing the trouble is related to the "vn_lock" function call?
What matters is that kio_write() may sleep and therefore can't be called
while holding a non-sleepable lock.
I don't understand though why the vnode lock would be set up in such a
way that when the write blocks whilst waiting for the underlying
filesystem to signal everything is ok, it causes the kernel to panic!
You cannot sleep while holding a non-sleepable lock. You need to find
out which locks are held at the point where you call kio_write(), and
figure out a way to delay the kio_write() call until those locks are
released.
How do I make the lock "sleepable" or make sure the thread doesn't try
go to sleep whilst holding the lock?
You can't make an unsleepable lock sleepable. You might be able to
replace it with a sleepable lock, but you would have to go through every
part of the kernel that uses the lock and make sure that it works
correctly with a sleepable lock. Most likely, it won't.
Thanks for the explanations. I'm starting to get a better picture of
what's actually going on.
So it seems that there is no way I can call kio_write from within the
function that is acting as a pfil output hook, because it blocks at some
point whilst doing the disk write, which makes the kernel unhappy
because pfil code is holding a non-sleepable mutex somewhere.
If you read my other message from yesterday, I still can't figure out
why this only happens with outbound TCP traffic, but anyways...
I'll have a bit more of a think about it and get back to the list shortly...
Cheers,
Lawrence
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
