public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cedric Le Goater <clg@fr.ibm.com>
To: Christoph Hellwig <hch@infradead.org>,
	Cedric Le Goater <clg@fr.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Neil Brown <neilb@suse.de>,
	nfs@lists.sourceforge.net
Subject: Re: [NFS] kthread: update lockd to use kthread
Date: Fri, 25 Aug 2006 19:07:59 +0200	[thread overview]
Message-ID: <44EF2E6F.1040905@fr.ibm.com> (raw)
In-Reply-To: <20060825135824.GA10659@infradead.org>

Hello !

Christoph Hellwig wrote:
>>  	host->h_nsmstate = newstate;
>>  	if (!host->h_reclaiming++) {
>> +		struct task_struct* task;
>> +
>>  		nlm_get_host(host);
>>  		__module_get(THIS_MODULE);
>> -		if (kernel_thread(reclaimer, host, CLONE_KERNEL) < 0)
>> +		task = kthread_run(reclaimer, host, "%s-reclaim", host->h_name);
>> +		if (IS_ERR(task))
>>  			module_put(THIS_MODULE);
> 
> Folks, this kind of patches is really useless.  If I wanted to just replace
> kernel_thread() with kthread_run() I could do it myself in a day or two.

ok ok. The real work that needs to be done is in sunrpc and I'm still
*very* far from providing any patches.

This kernel thread is a sub thread of the lockd thread. It's a bit more
simple and does not require as much modification. It still depends on the
way its parent is killed and it will require some more work when the sunrpc
thread are fixed.

> The whole point of the kthread API is that we now have a coherent set
> of functions that deal with all aspects of kernel thread handling.  And
> a conversion to that always involves rething the whole way a driver
> uses kernel threads, and that's a good thing because most users were
> buggy or at least rather odd.
>
> sunrpc is not an exception to that, the thread handling is very interesting,
> including things like using signals for various things possibly not waiting
> for threads to exit.

The SIGKILL used to terminate the threads is a challenge ... it propagates
to sub threads. Some other stuff that bother me in using the kthread api in
sunrpc : nfs_callback_down() uses a wait on a completion with a timeout.
This is not possible with the kthread but might not be really useful. dunno.

We might need some enhancements to kthread to make everyone happy or some
work around in the model.

> If you don't feel like poking into all these nasty internal leave the
> conversation to someone else, preferably a nfs developer.

They would certainly do a better job than me. I'm discovering the code.

Thanks,

C.


  reply	other threads:[~2006-08-25 17:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-25  7:25 kthread: update lockd to use kthread Cedric Le Goater
2006-08-25 13:58 ` [NFS] " Christoph Hellwig
2006-08-25 17:07   ` Cedric Le Goater [this message]
2006-08-29 11:50     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44EF2E6F.1040905@fr.ibm.com \
    --to=clg@fr.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox