linux-kernel - Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation

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: <4E6F5D2F.4050100@parallels.com>
Date:	Tue, 13 Sep 2011 17:39:59 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	Jeff Layton <jlayton@...hat.com>
CC:	Trond Myklebust <Trond.Myklebust@...app.com>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	Pavel Emelianov <xemul@...allels.com>,
	"neilb@...e.de" <neilb@...e.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"bfields@...ldses.org" <bfields@...ldses.org>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind
 clients creation

13.09.2011 16:51, Jeff Layton пишет:
> My assumption in reading this set (maybe wrong) was that this was a
> preliminary set for now that just plops in function calls in the places
> that do this sort of thing now. I figured that eventually he'd convert
> rpcb_create_local, et. al. to do the same thing but within the correct
> namespace for the calling task.
>

You have a right assumption. This is exactly what I'm going to do next.

>
> I think the simplest solution would be to basically call these
> functions closer to where the rpcbind calls happen today, and just
> don't do them when the svc_program has vs_hidden set or if the xprt is
> being created with SVC_SOCK_ANONYMOUS set.
>

This solution is not the simplest one since we call svc_register() for every svc 
socket if it's not anonymous. But svc_unregister() is called only once for all 
inet families and protocols.

Also I've noticed, that we call svc_unregister in __svc_create(). I.e. we call 
it for nfs callbacks as well (in spite of that we don't need this). Thus, for 
now, nfs callbacks service creation depends on rpcbind clients presence.

So, for my pow, we need something like startup() callback, passed to 
svc_create(_pooled)() to clean up this mess.
This callback will be defined only for lockd and nfsd and will create rpcbind 
clients and remove any stale portmap registrations.

-- 
Best regards,
Stanislav Kinsbursky
--
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/