linux-kernel - Re: [PATCH v2] ns: do not block exit_task

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: <20120716165301.GN31729@ZenIV.linux.org.uk>
Date:	Mon, 16 Jul 2012 17:53:01 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	"Dmitry V. Levin" <ldv@...linux.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Doug Ledford <dledford@...hat.com>,
	linux-kernel@...r.kernel.org, containers@...ts.linux-foundation.org
Subject: Re: [PATCH v2] ns: do not block exit_task_namespaces() for a long
 time

On Mon, Jul 16, 2012 at 06:09:24PM +0300, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
> 
> On exiting of the last task in a namespace we need to trigger freeing of
> the namespace. Currently, we call synchronize_rcu() and free_nsproxy()
> directly on do_exit() path.
> 
> On my machine synchronize_rcu() blocks for about 0.01 seconds. For
> comparing: normal exit_group() syscall takes less than 0.0003 seconds.
> 
> Let's offload synchronize_rcu() and free_nsproxy() to a workqueue.
> 
> I also move synchronize_rcu() inside free_nsproxy(). It fixes racy
> put_nsproxy() which calls free_nsproxy() without synchronize_rcu().
> I guess it was missed during switch to RCU (see cf7b708).

NAK.  Making final umounts of anything in that namespace asynchronous,
even though nothing is holding the stuff on them busy is simply
wrong.  Note that they can take a _long_ time, so we are talking about
minutes worth of delay in the worst case.  It's user-visible and
it's a serious potential for trouble.
--
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/