Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Oct 2007 12:37:33 -0700
From:      Julian Elischer <julian@elischer.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, Julian Elischer <julian@freebsd.org>, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/sys kthread.h src/sys/kern kern_kthread.c
Message-ID:  <472241FD.1080502@elischer.org>
In-Reply-To: <200710261524.51945.jhb@freebsd.org>
References:  <200710261703.l9QH3Nmt061137@repoman.freebsd.org> <200710261420.34168.jhb@freebsd.org> <4722399E.3090209@elischer.org> <200710261524.51945.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Friday 26 October 2007 03:01:50 pm Julian Elischer wrote:
>> John Baldwin wrote:
>>> On Friday 26 October 2007 01:03:22 pm Julian Elischer wrote:
>>>> julian      2007-10-26 17:03:22 UTC
>>>>
>>>>   FreeBSD src repository
>>>>
>>>>   Modified files:
>>>>     sys/sys              kthread.h 
>>>>     sys/kern             kern_kthread.c 
>>>>   Log:
>>>>   kthread_exit needs no stinkin argument.
>>> So an important property of the old kthread_exit() (now kproc_exit()) was 
> that 
>>> a kernel module could safely ensure that a kthread it created was out of 
> the 
>>> kernel module's text segment before returning from a module unload hook to 
>>> prevent kernel panics by sleeping on the proc pointer with the proc lock 
> like 
>>> so:
>>>
>>> 	mtx_lock(&mylock);
>>> 	PROC_LOCK(p);
>>> 	signal_death = 1;
>>> 	mtx_unlock(&mylock);
>>> 	msleep(p, &p->p_mtx, ...);
>>> 	PROC_UNLOCK(p);
>>>
>>> And have the main thread do this:
>>>
>>> 	...
>>> 	mtx_lock(&mylock);
>>> 	while (!signal_death) {
>>> 		... fetch work, may drop mylock...
>>> 	}
>>> 	mtx_unlock(&mylock);
>>> 	kthread_exit(0);
>> the kproc_exit still does..
>>
>> I didn't see any users of it in the code that I've switched to kthreads
>> so far so I haven't added it to the kthread_exit() yet.
> 
> Ok.  That needs to happen at some point so that more kprocs can be kthreads.  
> For example, ipmi(4) creates a kthread/kproc, so does random(4), fdc(4), and 
> I think ndis(4).

I'll check them out and see what the best solution is..

> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?472241FD.1080502>