linux-kernel - Re: [PATCH] [NFS]: Lock daemon start/stop rework.

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] [day] [month] [year] [list]

Date:	Tue, 11 Mar 2008 16:46:03 +0300
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Christoph Hellwig <hch@...radead.org>, trond.myklebust@....uio.no
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [NFS]: Lock daemon start/stop rework.

Christoph Hellwig wrote:
> On Wed, Jan 30, 2008 at 02:41:34PM +0300, Denis V. Lunev wrote:
>> The pid of the locking daemon can be substituted with a task struct
>> without a problem. Namely, the value if filled in the context of the lockd
>> thread and used in lockd_up/lockd_down.
>>
>> It is possible to save task struct instead and use it to kill the process.
>> The safety of this operation is guaranteed by the RCU, i.e. task can't
>> disappear without passing a quiscent state.
> 
> We have a patch series pending on the nfs list that does this plus a lot
> more in the area.
> 

Sorry for bringing it up that late, but I haven't found any patches doing
the same for nfs/callback.c. What are the plans about this code? Can we 
start turning this to kthreads? Or is there some grand rework pending in 
this code, so that we will just duplicate someone's work or cause unneeded 
patches conflicts?

You see, this code is the last user of kill_proc(), which in turn is the
last user of find_pid() which (in turn) is about to be removed.

Thanks,
Pavel
--
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/