Ugh, my mail client ate my reply, lemme try again.
> On 05-Oct-00 Boris Popov wrote:
>>      Hello,
>>      Currently I'm trying to make KLD which uses kernel threads
>> unloadable under recent -current. The prototype of functions looks like
>> this:
>> void
>> my_thread(void*arg)
>> {
>>      while(wearewanted) {
>>              do_something();
>>              tsleep();
>>      }
>>      exited = 1;
>>      kthread_exit(0);
>> }

You need Giant before calling kthread_exit().

>> void
>> my_unload()
>> {
>>      wearewanted = 0;
>>      while (!exited)
>>              tsleep(1sec);
>> }
>>      my_unload() function called from the module unload event which
>> issued from the kldunload() syscall.
>>      Unfortunately, kernel panics in the mtx_exit_hard() function.
>> After some examination I've found that two fields in the Giant mutex
>> structure set to unexpected values:

It should have died much earlier if you had INVARIANTS turned on. :(  It
looks like you are releasing a mutex you probably do not own because
cpu_exit() (called by exit1() -> exit() -> kthread_exit()) releases Giant
as one of its final tasks.

>> ----
>> empty mtx_blocked for mutex Giant
>> mtx_contested not in any list for mutex Giant
>> ----
>>      These messages printed by added diagnostics code. With this patch
>> (see attachment) it is possible to load and unload KLD without any
>> problems on UP machine except that the above messages printed. However,
>> I'm don't know if they are correct. (btw, 4.1 doesn't have this problem).

This patch is bogus I'm afraid.  A contested mutex should always have a
process waiting to grab it when it is released.


John Baldwin <[EMAIL PROTECTED]> --
PGP Key:
"Power Users Use the Power to Serve!"  -

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to