Re: [PATCH] Add module_kernel_thread for threads that live in modules.

From: Neil Brown (
Date: Mon Jun 16 2003 - 18:10:48 EST

On Monday June 16, wrote:
> Hi Neil,

Hi Rusty. Thanks for the comments... I probably should have Cc:ed you
in the first place....

> There are several problems with this patch. Ignoring the fact
> that you use __module_get. Firstly, you bump the module count
> permentantly while the thread is running: how does it ever get
> unloaded? Secondly, modprobe becomes your parent.

We seem to have very different views of the problem, as you seem to be
calling into question aspects that I thought were obviously correct.

   In all the cases I am interested in (nfsd, lockd,
   lockd-helper-thread), the thread is started by code running
   inside the module and so there will be a reference held on the
   module while the thread is being started, thus __module_get is the
   correct thing to do as "we know we already have a refcount"...

module count bumped permananelt while thread is running:
   well ofcourse, the thread runs code in the module which can only
   be done safely while we have a ref-count.
how does it ever get unloaded:
   the thread exits, the refcount drops, and the module can be
   In the case of nfsd, the threads get signalled and die gracefully.
   For lockd, the number of users (nfs mounts or nfsd threads) drops
   to zero, the process is signalled, and exits gracefully.
   For the lockd helper threads, the complete there assigned task and
   The threads I am thinking of aren't running "whenever the module is
   loaded". They are running "whenever their service is needed".
modprobe becomes your parent:
   No, modprobe has nothing to do with it in my case. rpc.nfsd, or
   mount_nfs or lockd might be the parent. I thought reparent_to_init
   handled all that. Apparently there are question marks over that
   which I wasn't aware of.

> There have been ambitious attempts to do a nice "thread
> creation and stopping" interface before. Given the delicate logic
> involved in shutting threads down, I think this makes sense. Maybe
> something like:
> /* Struct which identifies a kernel thread, handed to creator and
> thread. */
> struct kthread
> {
> int pid;
> int should_die; /* Thread should exit when this is set. */
> /* User supplied arg... */
> void *arg;
> };
> struct kthread *create_thread(int (*fn)(struct kthread*), void *arg,
> unsigned long flags,
> const char *namefmt, ...);
> void cleanup_thread(struct kthread *);
> create_thread would use keventd to start the thread, and stop_thread
> would tell keventd to set should_die, wmb(), wake it up, and
> sys_wait() for it.
> Thoughts?

I don't want to have to call "cleanup_thread" or de-allocate the
"struct kthread". I want to be able to SIGKILL a process and have it
go away and release everything, including possibly the last refernce
to the module.

In short, it really feels like we are trying to solve different
problems :-)

I will have a look at keventd and see if it's services can be of
assistance to solve my problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:20 EST