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]
Message-ID: <20110913095204.7904c051@corrin.poochiereds.net>
Date:	Tue, 13 Sep 2011 09:52:04 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Stanislav Kinsbursky <skinsbursky@...allels.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

On Tue, 13 Sep 2011 17:39:59 +0400
Stanislav Kinsbursky <skinsbursky@...allels.com> wrote:

> 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.
> 

Ahh ok, good point.

> 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.
> 

Yeah, that's just to remove the any existing registration before we set
up the new one. In the case of a "hidden" service that can probably be
skipped if it makes things easier.

> 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.
> 

That sounds like a reasonable scheme. I'll wait to see the patches.

-- 
Jeff Layton <jlayton@...hat.com>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ