Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2501698imu; Tue, 6 Nov 2018 16:07:44 -0800 (PST) X-Google-Smtp-Source: AJdET5dYehefGh2VNwmqlyFhZMYDFGuOhI9tekOksNNnnZSaMckknygJqLOPF1DzSMIPhWLPYYqZ X-Received: by 2002:a65:610e:: with SMTP id z14-v6mr25613444pgu.138.1541549264876; Tue, 06 Nov 2018 16:07:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541549264; cv=none; d=google.com; s=arc-20160816; b=t7AEK/FY9BuN+MzpnAwlgJbkBSWpUS/2tt7VFoC1vldNeGCjb+dk/d0wwR03Mu95kj eiAQzkv4chkDqobk6n+hnCZt6rJOAxlyG5PjvIDRKjJ8MEaI671M1Bfq+ApSD2Z3U6sa MCHAVGhovObM8ny7PlNKtNzIA8+XqbKenxsDhtz/hn6oHAIDKQBW6nHeicHBHkRBK0gy 89fWsTYPFimo5WTiNShtAEsCawacEPEkIJQ8LVHpt/IaAtJ5Xf99jzwKq2W6x9Z6IVGl W2FvuWS+V197K1qhZLhVYmRP72yIiEb/S+/IkF/tvEcwZj5WKMGhS6ipq6pNQJoJj0iQ 3KYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=vMoX62BQ0kVnRws/yuyigTpMZ5MK2Vy3HmoS2zI+ods=; b=WPx5Kn9uEf+fJ99q90PWTz3x5fu9F8W+pAARtsGrA/0aeY67QWmaujOcrtecU24+Mf dQk7FSsPomSU9uBhIlWZ39jEdsqMyygTaMRUixJZRzWexYCwwJXL6xqMy4MQKv1EWH5k muE6gP+sqUReUOfnwO/vpZv3p9o3wRvdR3X7vY1oNegUXlCSDRe/sUTPKTUmq0dk39Cj rcCPKo9/G+1hnnMBnp4Y48DDcWY4APePXKOyzqms0U6BGlhUpYMj6AdFyU1z6X4TcibE nM2xnn6nrZpvMxbAJ/SPRC9PolSNvo8zkxQSH/mW0IFGgOufgJ4PdRalu/1VF+P/6nUW r1bA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y13si20962369pgj.157.2018.11.06.16.07.29; Tue, 06 Nov 2018 16:07:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731026AbeKGJez (ORCPT + 99 others); Wed, 7 Nov 2018 04:34:55 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:48880 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730931AbeKGJez (ORCPT ); Wed, 7 Nov 2018 04:34:55 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id ED44B88A; Wed, 7 Nov 2018 00:07:05 +0000 (UTC) Date: Tue, 6 Nov 2018 16:07:01 -0800 From: Andrew Morton To: =?UTF-8?B?Y2hvdXJ5emhvdQ==?= (=?UTF-8?B?5ZGo5aiB?=) Cc: "gregkh@linuxfoundation.org" , "arve@android.com" , "tkjos@android.com" , "dave@stgolabs.net" , "devel@driverdev.osuosl.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH V2] binder: ipc namespace support for android binder Message-Id: <20181106160701.5e73de3056dee7aa560e43a3@linux-foundation.org> In-Reply-To: <5FBCBE569E134E4CA167B91C0A77FD610198F6BB7D@EXMBX-SZMAIL022.tencent.com> References: <5FBCBE569E134E4CA167B91C0A77FD610198F6BB7D@EXMBX-SZMAIL022.tencent.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Oct 2018 06:18:11 +0000 chouryzhou(周威) wrote: > We are working for running android in container, but we found that binder is > not isolated by ipc namespace. Since binder is a form of IPC and therefore should > be tied to ipc namespace. With this patch, we can run more than one android > container on one host. > This patch move "binder_procs" and "binder_context" into ipc_namespace, > driver will find the context from it when opening. Althought statistics in debugfs > remain global. > > ... > > --- a/ipc/namespace.c > +++ b/ipc/namespace.c > @@ -56,6 +56,9 @@ static struct ipc_namespace *create_ipc_ns(struct user_namespace *user_ns, > ns->ucounts = ucounts; > > err = mq_init_ns(ns); > + if (err) > + goto fail_put; > + err = binder_init_ns(ns); > if (err) > goto fail_put; > Don't we need an mq_put_mnt() if binder_init_ns() fails? free_ipc_ns() seems to have forgotten about that too. In which case it must be madly leaking mounts so probably I'm wrong. Confused.