linux-kernel - Re: 3.4. sunrpc oops during shutdown

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 29 May 2012 07:21:41 -0400
From:	"bfields@...ldses.org" <bfields@...ldses.org>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	Stanislav Kinsbursky <skinsbursky@...allels.com>,
	Dave Jones <davej@...hat.com>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 3.4. sunrpc oops during shutdown

On Mon, May 28, 2012 at 11:43:40PM +0000, Myklebust, Trond wrote:
> On Fri, 2012-05-25 at 17:31 +0400, Stanislav Kinsbursky wrote:
> > Yes. But unfortunately, this won't be enough.
> > "NFS: callback threads containerization" patch set is required as well.
> > 
> > A a bugfix, I can suggest "SUNRPC: separate per-net data creation from service" 
> > patch set + pass hard-coded "init_net" for NFS callback shutdown routines 
> > (instead of current->nsproxy->net_ns). This should work.
> 
> Hi Stanislav,
> 
> My question is why should svc_destroy() care about net namespaces at
> all? Once an application is calling svc_destroy(), it is trying to close
> down the entire service. It really should not matter to which net
> namespace a particular socket belongs: they _all_ need to be destroyed.

Services started in different network namespaces should be
independent--for example, starting nfsd in container A and then again in
container B, then shutting it down in container A, shouldn't also shut
down container B's service.

*But* there is currently only a single global server object, because
we're sharing threads:

	http://marc.info/?l=linux-nfs&m=133405747330055&w=2

	"Having Lockd thread (or NFSd threads) per container looks easy
	to implement on first sight. But kernel threads currently
	supported only in initial pid namespace. I.e. it means that
	per-container kernel thread won't be visible in container, if it
	has it's own pid namespace. And there is no way to put a kernel
	thread into container.  In OpenVZ we have per-container kernel
	threads. But integrating this feature to mainline looks hopeless
	(or very difficult) to me. At least for now.  So this problem
	with signals remains unsolved.

	"So, as it looks to me, this "one service per all" is the only
	one suitable for now."

so Stanislav is simulating multiple servers by shutting down sockets on
a per-net basis.

But I think it should be possible to share threads between servers while
still behaving in every other way as if the servers are completely
independent.

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