linux-kernel - Re: [NFS] [PATCH 004 of 19] knfsd: lockd: introduce nsm

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: <20060904084846.GB28400@suse.de>
Date:	Mon, 4 Sep 2006 10:48:46 +0200
From:	Olaf Kirch <okir@...e.de>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	NeilBrown <neilb@...e.de>, Andrew Morton <akpm@...l.org>,
	nfs@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [NFS] [PATCH 004 of 19] knfsd: lockd: introduce nsm_handle

On Fri, Sep 01, 2006 at 12:41:33PM -0400, Trond Myklebust wrote:
> The local statd process is supposed to decode the notification from the
> remote client/server, and then notify the kernel. It already sends that
> notification on a per-nlm_host basis (i.e. it the call down to the
> kernel contains the <address,version,transport protocol>.

Why does statd need to send the full <address,version,transport protocol>
to the kernel in the first place?

All that's really needed is a unique identification of the host having
rebooted, nevermind how we have been talking to it, and in what role.

I consider the current practice a side effect of a bad implementation
which duplicates a lot of state by dumping everything into the nlm_host.

With the current code, we cannot even monitor IPv6 addresses, because
there's not enough room in the NSM_MON packet. With my proposed change,
we can ditch version and transport protocol, and all of a sudden we
have 16 bytes for the address - ie enough to make IPv6 happy.

In the long run, we could clean out nlm_host even more - there's
a lot of cruft in there.

	h_name		just h_nsmhandle->sm_name
	h_gracewait	could be shared as well
	h_state		should move to nsmhandle as well
	h_nsmstate	currently not used, could move to nsmhandle as well
	h_pidcount	currently allocated per nlm_host, which leads
			to aliasing if we mix NFSv2 and v3 mounts

On a side note, we may want to always allocate an RPC client for each
nlm_host.  Then we can ditch the following variables as well, which are
in the rpc_client's portmap info anyway:

	h_proto		pm_prot
	h_version	pm_vers
	h_sema		useless
	h_nextrebind	we can stop rebinding every 60s, the sunrpc
			doesn't need that anymore. During recovery,
			we can just call rpc_force_rebind
			directly.

Or going even further, one could make the nlm_host agnostic of transports
and protocol versions. Just stick a (short) array of RPC clients in the
nlm_host - any code that places NLM calls will need some extra logic
to select the right client, but it would save on memory and reduce
complexity.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@...e.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-- 
VGER BF report: H 2.68873e-09
-
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/