From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754066AbbJPKNv (ORCPT <rfc822;w@1wt.eu>);
	Fri, 16 Oct 2015 06:13:51 -0400
Received: from mailout3.w1.samsung.com ([210.118.77.13]:37374 "EHLO
	mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752787AbbJPKNt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 16 Oct 2015 06:13:49 -0400
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
X-AuditID: cbfec7f5-f794b6d000001495-2f-5620cdda73fb
Content-transfer-encoding: 8BIT
Message-id: <1444990425.5661.12.camel@samsung.com>
Subject: Re: [PATCH v4 09/11] smack: namespace groundwork
From: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
To: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: "'Andy Lutomirski'" <luto@amacapital.net>,
        "'Kees Cook'" <keescook@chromium.org>,
        "'linux-kernel'" <linux-kernel@vger.kernel.org>,
        linux-security-module@vger.kernel.org
Date: Fri, 16 Oct 2015 12:13:45 +0200
In-reply-to: <026701d107bf$6ef3e280$4cdba780$@alibaba-inc.com>
References: <019801d1071b$2c124000$8436c000$@alibaba-inc.com>
 <01a101d1071c$8ce631b0$a6b29510$@alibaba-inc.com>
 <1444912906.5661.7.camel@samsung.com> <1444913602.5661.9.camel@samsung.com>
 <026701d107bf$6ef3e280$4cdba780$@alibaba-inc.com>
X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsVy+t/xq7q3ziqEGfzrtLCYO/8wu8WZ7lyL
	y7vmsFl86HnEZrF6bQOrA6vHxLcfWTzuv/nL4jG74SKLx+dNcgEsUVw2Kak5mWWpRfp2CVwZ
	N75OYSvYwFnRPuU5awPjJ7YuRk4OCQETidbDK6BsMYkL99aD2UICSxkl9n8KArF5BQQlfky+
	x9LFyMHBLCAvceRSNkiYWUBdYtK8RcxdjFxA5Z8ZJfp+zWCBqDeSeP5mNdgcYQFLidv7LoDZ
	bAIGEt8v7GUGsUUEtCVeffnDCNLMLLCGUeLNto9gCRYBVYnmGxvAbE4BO4njzQ9Z4TZ8v/Gf
	FeJSLYmDz58yTWAUmIXkwFkIB85CcuACRuZVjKKppckFxUnpuUZ6xYm5xaV56XrJ+bmbGCFB
	/HUH49JjVocYBTgYlXh4GewUwoRYE8uKK3MPMUpwMCuJ8NrsBwrxpiRWVqUW5ccXleakFh9i
	lOZgURLnnbnrfYiQQHpiSWp2ampBahFMlomDU6qBUcDc9iSL67q+CU+4vKo1a2eoO3BuENg8
	P+eI742+bDWvQNGNGWF2QXevx+wMMlxbsGllwbf9U/UZp57dvGey05aJRcLcZltULb/tky1d
	WM20LF4opzG8b33qMfE3+/d9Osm8eJOqb8VsiX0bBfY97KrN/Vuc82CWy+JwR/e77osUquqn
	qGRfVmIpzkg01GIuKk4EAKTuDmVeAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On pią, 2015-10-16 at 11:04 +0800, Hillf Danton wrote:
> > +
> >  static inline void smack_userns_free(struct user_namespace *ns)
> >  {
> >         struct smack_ns *snsp = ns->security;
> > @@ -4680,12 +4689,11 @@ static inline void smack_userns_free(struct
> > user_namespace *ns)
> > 
> >                 mutex_lock(&skp->smk_mapped_lock);
> >                 list_del_rcu(&sknp->smk_list_known);
> > -               if (sknp->smk_allocated)
> > -                       kfree(sknp->smk_mapped);
> > -               kfree(sknp);
> >                 mutex_unlock(&skp->smk_mapped_lock);
> > 
> >                 list_del(&sknp->smk_list_ns);
> 
> Is list_del safe, given the operation
> 
> +	mutex_lock(&snsp->smk_mapped_lock);
> +	list_add_rcu(&sknp->smk_list_ns, &snsp->smk_mapped);
> +	mutex_unlock(&snsp->smk_mapped_lock);
> 
> in smk_import_mapped() function(copied below)?

Yes, the namespace is destroyed when all its references are gone. This
also includes processes that were in that namespace. Meaning there is
no way to import a new mapping for them anymore at this point.


-- 
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics