linux-kernel - Re: [NFS] kthread: update lockd to use kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44EF2E6F.1040905@fr.ibm.com>
Date:	Fri, 25 Aug 2006 19:07:59 +0200
From:	Cedric Le Goater <clg@...ibm.com>
To:	Christoph Hellwig <hch@...radead.org>,
	Cedric Le Goater <clg@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Neil Brown <neilb@...e.de>, nfs@...ts.sourceforge.net
Subject: Re: [NFS] kthread: update lockd to use kthread

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/