[{"id":1757892,"web_url":"http://patchwork.ozlabs.org/comment/1757892/","msgid":"<59A0D62F.3030806@iogearbox.net>","list_archive_url":null,"date":"2017-08-26T02:00:15","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":65705,"url":"http://patchwork.ozlabs.org/api/people/65705/","name":"Daniel Borkmann","email":"daniel@iogearbox.net"},"content":"On 08/25/2017 09:05 PM, David Ahern wrote:\n> Add support for recursively applying sock filters attached to a cgroup.\n> For now, start with the inner cgroup attached to the socket and work back\n> to the root or first cgroup without the recursive flag set. Once the\n> recursive flag is set for a cgroup all descendant group's must have the\n> flag as well.\n>\n> Signed-off-by: David Ahern \n[...]\n> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h\n> index f71f5e07d82d..595e31b30f23 100644\n> --- a/include/uapi/linux/bpf.h\n> +++ b/include/uapi/linux/bpf.h\n> @@ -151,6 +151,15 @@ enum bpf_attach_type {\n> */\n> #define BPF_F_ALLOW_OVERRIDE\t(1U << 0)\n>\n> +/* If BPF_F_RECURSIVE flag is used in BPF_PROG_ATTACH command\n> + * cgroups are walked recursively back to the root cgroup or the\n> + * first cgroup without the flag set running any program attached.\n> + * Once the flag is set, it MUST be set for all descendant cgroups.\n> + */\n> +#define BPF_F_RECURSIVE\t\t(1U << 1)\n> +\n> +#define BPF_F_ALL_ATTACH_FLAGS (BPF_F_ALLOW_OVERRIDE | BPF_F_RECURSIVE)\n> +\n> /* If BPF_F_STRICT_ALIGNMENT is used in BPF_PROG_LOAD command, the\n> * verifier will perform strict alignment checking as if the kernel\n> * has been built with CONFIG_EFFICIENT_UNALIGNED_ACCESS not set,\n> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c\n> index 546113430049..eb1f436c18fb 100644\n> --- a/kernel/bpf/cgroup.c\n> +++ b/kernel/bpf/cgroup.c\n> @@ -47,10 +47,16 @@ void cgroup_bpf_inherit(struct cgroup *cgrp, struct cgroup *parent)\n> \tunsigned int type;\n>\n> \tfor (type = 0; type < ARRAY_SIZE(cgrp->bpf.effective); type++) {\n> -\t\tstruct bpf_prog *e;\n> +\t\tstruct bpf_prog *e = NULL;\n> +\n> +\t\t/* do not need to set effective program if cgroups are\n> +\t\t * walked recursively\n> +\t\t */\n> +\t\tcgrp->bpf.is_recursive[type] = parent->bpf.is_recursive[type];\n> +\t\tif (!cgrp->bpf.is_recursive[type])\n> +\t\t\te = rcu_dereference_protected(parent->bpf.effective[type],\n> +\t\t\t\t\t\t lockdep_is_held(&cgroup_mutex));\n\n[...]\n\n> -\t\te = rcu_dereference_protected(parent->bpf.effective[type],\n> -\t\t\t\t\t lockdep_is_held(&cgroup_mutex));\n> \t\trcu_assign_pointer(cgrp->bpf.effective[type], e);\n> \t\tcgrp->bpf.disallow_override[type] = parent->bpf.disallow_override[type];\n> \t}\n[...]\n> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c\n> index d5774a6851f1..a1ab5dbaae89 100644\n> --- a/kernel/bpf/syscall.c\n> +++ b/kernel/bpf/syscall.c\n> @@ -1187,7 +1187,7 @@ static int bpf_prog_attach(const union bpf_attr *attr)\n> \tif (CHECK_ATTR(BPF_PROG_ATTACH))\n> \t\treturn -EINVAL;\n>\n> -\tif (attr->attach_flags & ~BPF_F_ALLOW_OVERRIDE)\n> +\tif (attr->attach_flags & ~BPF_F_ALL_ATTACH_FLAGS)\n> \t\treturn -EINVAL;\n>\n> \tswitch (attr->attach_type) {\n> @@ -1222,7 +1222,7 @@ static int bpf_prog_attach(const union bpf_attr *attr)\n> \t}\n>\n> \tret = cgroup_bpf_update(cgrp, prog, attr->attach_type,\n> -\t\t\t\tattr->attach_flags & BPF_F_ALLOW_OVERRIDE);\n> +\t\t\t\tattr->attach_flags);\n> \tif (ret)\n> \t\tbpf_prog_put(prog);\n> \tcgroup_put(cgrp);\n> @@ -1252,7 +1252,7 @@ static int bpf_prog_detach(const union bpf_attr *attr)\n> \t\tif (IS_ERR(cgrp))\n> \t\t\treturn PTR_ERR(cgrp);\n>\n> -\t\tret = cgroup_bpf_update(cgrp, NULL, attr->attach_type, false);\n> +\t\tret = cgroup_bpf_update(cgrp, NULL, attr->attach_type, 0);\n> \t\tcgroup_put(cgrp);\n> \t\tbreak;\n\nCan you elaborate on the semantical changes for the programs\nsetting the new flag which are not using below cgroup_bpf_run_filter_sk()\nhelper to walk back to root?\n\n> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c\n> index df2e0f14a95d..27a4f14435a3 100644\n> --- a/kernel/cgroup/cgroup.c\n> +++ b/kernel/cgroup/cgroup.c\n> @@ -5176,14 +5176,35 @@ void cgroup_sk_free(struct sock_cgroup_data *skcd)\n>\n> #ifdef CONFIG_CGROUP_BPF\n> int cgroup_bpf_update(struct cgroup *cgrp, struct bpf_prog *prog,\n> -\t\t enum bpf_attach_type type, bool overridable)\n> +\t\t enum bpf_attach_type type, u32 flags)\n> {\n> \tstruct cgroup *parent = cgroup_parent(cgrp);\n> \tint ret;\n>\n> \tmutex_lock(&cgroup_mutex);\n> -\tret = __cgroup_bpf_update(cgrp, parent, prog, type, overridable);\n> +\tret = __cgroup_bpf_update(cgrp, parent, prog, type, flags);\n> \tmutex_unlock(&cgroup_mutex);\n> \treturn ret;\n> }\n> +\n> +int cgroup_bpf_run_filter_sk(struct sock *sk,\n> +\t\t\t enum bpf_attach_type type)\n> +{\n> +\tstruct cgroup *cgrp = sock_cgroup_ptr(&sk->sk_cgrp_data);\n> +\tint ret = 0;\n> +\n> +\twhile (cgrp) {\n> +\t\tret = __cgroup_bpf_run_filter_sk(cgrp, sk, type);\n> +\t\tif (ret)\n> +\t\t\tbreak;\n> +\n> +\t\tif (!cgrp->bpf.is_recursive[type])\n> +\t\t\tbreak;\n> +\n> +\t\tcgrp = cgroup_parent(cgrp);\n> +\t}\n> +\n> +\treturn ret;\n> +}\n> +EXPORT_SYMBOL(cgroup_bpf_run_filter_sk);\n> #endif /* CONFIG_CGROUP_BPF */\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xfLqf56vhz9t48\n\tfor ;\n\tSat, 26 Aug 2017 12:01:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751532AbdHZCAZ (ORCPT );\n\tFri, 25 Aug 2017 22:00:25 -0400","from www62.your-server.de ([213.133.104.62]:39925 \"EHLO\n\twww62.your-server.de\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751407AbdHZCAY (ORCPT\n\t); Fri, 25 Aug 2017 22:00:24 -0400","from [92.105.166.74] (helo=localhost.localdomain)\n\tby www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256)\n\t(Exim 4.85_2) (envelope-from )\n\tid 1dlQOc-0003wE-L8; Sat, 26 Aug 2017 04:00:22 +0200"],"Message-ID":"<59A0D62F.3030806@iogearbox.net>","Date":"Sat, 26 Aug 2017 04:00:15 +0200","From":"Daniel Borkmann ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Thunderbird/31.7.0","MIME-Version":"1.0","To":"David Ahern , netdev@vger.kernel.org,\n\tast@kernel.org, tj@kernel.org, davem@davemloft.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>","In-Reply-To":"<1503687941-626-2-git-send-email-dsahern@gmail.com>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit","X-Authenticated-Sender":"daniel@iogearbox.net","X-Virus-Scanned":"Clear (ClamAV 0.99.2/23714/Sat Aug 26 02:36:06 2017)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1757897,"web_url":"http://patchwork.ozlabs.org/comment/1757897/","msgid":"<20170826024957.m5ita6usxihywmdd@ast-mbp>","list_archive_url":null,"date":"2017-08-26T02:49:58","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Fri, Aug 25, 2017 at 12:05:34PM -0700, David Ahern wrote:\n> Add support for recursively applying sock filters attached to a cgroup.\n> For now, start with the inner cgroup attached to the socket and work back\n> to the root or first cgroup without the recursive flag set. Once the\n> recursive flag is set for a cgroup all descendant group's must have the\n> flag as well.\n> \n> Signed-off-by: David Ahern \n> ---\n> include/linux/bpf-cgroup.h | 10 ++++++----\n> include/uapi/linux/bpf.h | 9 +++++++++\n> kernel/bpf/cgroup.c | 29 ++++++++++++++++++++++-------\n> kernel/bpf/syscall.c | 6 +++---\n> kernel/cgroup/cgroup.c | 25 +++++++++++++++++++++++--\n> 5 files changed, 63 insertions(+), 16 deletions(-)\n> \n> diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h\n> index d41d40ac3efd..2d02187f242f 100644\n> --- a/include/linux/bpf-cgroup.h\n> +++ b/include/linux/bpf-cgroup.h\n> @@ -23,6 +23,7 @@ struct cgroup_bpf {\n> \tstruct bpf_prog *prog[MAX_BPF_ATTACH_TYPE];\n> \tstruct bpf_prog __rcu *effective[MAX_BPF_ATTACH_TYPE];\n> \tbool disallow_override[MAX_BPF_ATTACH_TYPE];\n> +\tbool is_recursive[MAX_BPF_ATTACH_TYPE];\n> };\n> \n> void cgroup_bpf_put(struct cgroup *cgrp);\n> @@ -30,18 +31,19 @@ void cgroup_bpf_inherit(struct cgroup *cgrp, struct cgroup *parent);\n> \n> int __cgroup_bpf_update(struct cgroup *cgrp, struct cgroup *parent,\n> \t\t\tstruct bpf_prog *prog, enum bpf_attach_type type,\n> -\t\t\tbool overridable);\n> +\t\t\tu32 flags);\n> \n> /* Wrapper for __cgroup_bpf_update() protected by cgroup_mutex */\n> int cgroup_bpf_update(struct cgroup *cgrp, struct bpf_prog *prog,\n> -\t\t enum bpf_attach_type type, bool overridable);\n> +\t\t enum bpf_attach_type type, u32 flags);\n> \n> int __cgroup_bpf_run_filter_skb(struct sock *sk,\n> \t\t\t\tstruct sk_buff *skb,\n> \t\t\t\tenum bpf_attach_type type);\n> \n> -int __cgroup_bpf_run_filter_sk(struct sock *sk,\n> +int __cgroup_bpf_run_filter_sk(struct cgroup *cgrp, struct sock *sk,\n> \t\t\t enum bpf_attach_type type);\n> +int cgroup_bpf_run_filter_sk(struct sock *sk, enum bpf_attach_type type);\n> \n> int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,\n> \t\t\t\t struct bpf_sock_ops_kern *sock_ops,\n> @@ -74,7 +76,7 @@ int __cgroup_bpf_run_filter_sock_ops(struct sock *sk,\n> ({\t\t\t\t\t\t\t\t\t \\\n> \tint __ret = 0;\t\t\t\t\t\t\t \\\n> \tif (cgroup_bpf_enabled && sk) {\t\t\t\t\t \\\n> -\t\t__ret = __cgroup_bpf_run_filter_sk(sk,\t\t\t \\\n> +\t\t__ret = cgroup_bpf_run_filter_sk(sk,\t\t\t \\\n> \t\t\t\t\t\t BPF_CGROUP_INET_SOCK_CREATE); \\\n> \t}\t\t\t\t\t\t\t\t \\\n> \t__ret;\t\t\t\t\t\t\t\t \\\n> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h\n> index f71f5e07d82d..595e31b30f23 100644\n> --- a/include/uapi/linux/bpf.h\n> +++ b/include/uapi/linux/bpf.h\n> @@ -151,6 +151,15 @@ enum bpf_attach_type {\n> */\n> #define BPF_F_ALLOW_OVERRIDE\t(1U << 0)\n> \n> +/* If BPF_F_RECURSIVE flag is used in BPF_PROG_ATTACH command\n> + * cgroups are walked recursively back to the root cgroup or the\n> + * first cgroup without the flag set running any program attached.\n> + * Once the flag is set, it MUST be set for all descendant cgroups.\n> + */\n> +#define BPF_F_RECURSIVE\t\t(1U << 1)\n\nabove logic makes sense, but ...\n\n> +\tif (prog && curr_recursive && !new_recursive)\n> +\t\t/* if a parent has recursive prog attached, only\n> +\t\t * allow recursive programs in descendent cgroup\n> +\t\t */\n> +\t\treturn -EINVAL;\n> +\n> \told_prog = cgrp->bpf.prog[type];\n\n... I'm struggling to completely understand how it interacts\nwith BPF_F_ALLOW_OVERRIDE.\nBy default we shouldn't allow overriding, so if default prog attached\nto a root, what happens if we try to attach F_RECURSIVE to a descendent?\nIf I'm reading the code correctly it will not succeed, which is good.\nCould you add such scenario as test to test_cgrp2_attach2.c ?\n\nNow say we attach overridable and !recursive to a root, another\nrecursive prog will not be attached to a descedent, which is correct.\n\nBut if we attach !overridable + recursive to a root we cannot attach\nanything to a descendent right? Then why allow such combination at all?\nSo only overridable + recursive combination makes sense, right?\n\nI think all these combinations must be documented and tests must be\nadded. Sooner or later people will build security sensitive environment\nwith it and we have to meticulous now.\n\nDo you think it would make sense to split this patch out and\npush patches 2 and 3 with few tests in parallel, while we're review\nthis change?\n\nTejun needs to take a deep look into this patch as well.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"f+rYhhya\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xfMvn4dtLz9t4X\n\tfor ;\n\tSat, 26 Aug 2017 12:50:13 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754033AbdHZCuD (ORCPT );\n\tFri, 25 Aug 2017 22:50:03 -0400","from mail-pf0-f195.google.com ([209.85.192.195]:35860 \"EHLO\n\tmail-pf0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751508AbdHZCuC (ORCPT\n\t); Fri, 25 Aug 2017 22:50:02 -0400","by mail-pf0-f195.google.com with SMTP id a2so174838pfj.3\n\tfor ; Fri, 25 Aug 2017 19:50:01 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:c89a])\n\tby smtp.gmail.com with ESMTPSA id\n\tc19sm14559649pfk.3.2017.08.25.19.49.59\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 25 Aug 2017 19:50:00 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=3B8000w7JuswuMCC/p3Qx0+2tvA7eTXdtEd1TXEaIIs=;\n\tb=f+rYhhyaTNBnwztiLSD8ZlDQm0apBI4skDik0beupRSQJKtGEappCI5vVOEtXKXvoG\n\tk38NzNTMDHlev6WaZuSL84/50NOY6G2mTlPBaHCY4uTzV8EAJYWpHyoV13jST/N3jMbj\n\tXQr/L2vMnmSTw5EfavCT0/ASO2Ro4K7sSlhkUtDX7+pF6yVuFs1EzHWt0qRcRrl0Lg1u\n\tL39Sskc7HSNfZtN4QH+4ES9a/r90L8WhVvHKrJ/qxpr5VBFrz2BHM5boWEorukADVUGi\n\tpRIoKVMYn5hlRbwS9q2eUUQkQ1/U4fx9ie9gxYpD+knXUkeWXwkbu9A+3Q0DBsTfY9Ue\n\tF1kw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=3B8000w7JuswuMCC/p3Qx0+2tvA7eTXdtEd1TXEaIIs=;\n\tb=mBsVZJyn0qNFz6SFrCVTPwanKKj7sLRy9JpFnR9fRtsUy0dZvRjptoDqAMPbh0hQaC\n\thpCgiY1yLTUF9Cgcb5maEMO1NzFDqEEoKByflq/8pWUrB6xatPvO/JpmDQs4gnXLqn0V\n\tXnZWznGzPcBoJyKc6EpbX5lu/WaPWOEaKMP+asXu4U5BgX9y8226Pil0VD/p1BJvQbjK\n\tes3hvc3AOc5X8L48A9CE8PGQE/eP2CpajO1+slF/7DXIfpAwjNorS3dXieAJibz1XrsT\n\thCEQapQBqc3R5lUrD0eBB8LWKBcuKaCz4J4P0eNHDwClPnRhxfBvHqPZsxtqdCZbxbsd\n\t7HGA==","X-Gm-Message-State":"AHYfb5i4+RYDU9btSsueeca/EX93YNbvwW1J+wi5JP0wFcIL8EY9xK6v\n\tR6JP3EEFt47H4w==","X-Received":"by 10.99.177.14 with SMTP id r14mr529753pgf.9.1503715801352;\n\tFri, 25 Aug 2017 19:50:01 -0700 (PDT)","Date":"Fri, 25 Aug 2017 19:49:58 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170826024957.m5ita6usxihywmdd@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1503687941-626-2-git-send-email-dsahern@gmail.com>","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758266,"web_url":"http://patchwork.ozlabs.org/comment/1758266/","msgid":"<819aab80-b898-9eb8-36e2-759d2addca0d@gmail.com>","list_archive_url":null,"date":"2017-08-27T14:22:59","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/25/17 8:00 PM, Daniel Borkmann wrote:\n> Can you elaborate on the semantical changes for the programs\n> setting the new flag which are not using below cgroup_bpf_run_filter_sk()\n> helper to walk back to root?\n\nYou mean other cgroup based programs -- BPF_CGROUP_* ? If so, any reason\nnot to allow the recursion model on those too?","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"kVbcGE9Z\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xgHLM12LQz9sD9\n\tfor ;\n\tMon, 28 Aug 2017 00:27:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751447AbdH0OXC (ORCPT );\n\tSun, 27 Aug 2017 10:23:02 -0400","from mail-pf0-f196.google.com ([209.85.192.196]:36606 \"EHLO\n\tmail-pf0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751390AbdH0OXB (ORCPT\n\t); Sun, 27 Aug 2017 10:23:01 -0400","by mail-pf0-f196.google.com with SMTP id a2so2434415pfj.3\n\tfor ; Sun, 27 Aug 2017 07:23:01 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:c1bc:2493:e932:bac3])\n\tby smtp.googlemail.com with ESMTPSA id\n\ts81sm734318pfg.78.2017.08.27.07.22.59\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSun, 27 Aug 2017 07:22:59 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:references:from:message-id:date:user-agent:mime-version\n\t:in-reply-to:content-language:content-transfer-encoding;\n\tbh=bPLKn/lCts8Pqagoc/yxQI1PZgJQgODWBVgUQbPpknM=;\n\tb=kVbcGE9ZQylpouHWaq1eCw2HfvPSpQ0FQvevpA9+BYr8z4PVGZEXQrJ+xqqD20Za5A\n\tWOlfwlFKBAInuJpI/dIAeo8BzFWz5ZkIh0Da4qzPMxQ5KkFP4R/i7cVxRyk48UTIHwV2\n\tTbLO9L7mYO/3ChWi2OxcgN7Rwp9hksyx7sQH1+pO4VDaQs52XHhNrT0urgNyM+hupuPu\n\tqGmT4+vCWZZhhYzweKTA1a0w91lmXiDX0/RX6asZTCHdbUmBMKdQXQcEtvTCas7sTiQm\n\t574vCRfdspuqaP8vJQbMw+3k9b8qo0LQF56Sm2kVkYCap7v0kIeCMMsrFN8jUl3yb2LA\n\tfHzw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=bPLKn/lCts8Pqagoc/yxQI1PZgJQgODWBVgUQbPpknM=;\n\tb=T4LEs1ZgnhL2HEWOE98bVTxb4q4IfWLuHfIA289vYqvzxm8i5fOguPJozls5DDBtBv\n\t+McA8tkqxgAY0+mk8ag+UO5u6qSE765bwluCwYAx7NxL1jK80vbAnaWRLzvSrQOZZM8N\n\tVKruoV/S9e6T3GWjrYxe3LNgrqOMi2VztaiC3km46aUZqaT9Yk+lSQNjlb2teA2mXRgX\n\tFEgPYfBfHOQmoPCKEvZHUGGtxCWEaMQO0A43J374nNYEVQneb3gm0NR/j9dP4Tfe/yJ6\n\tJJfdy5AOf52s/9C9h2kyT5fysOGUb+egUw8rXd6bCez/fiJs4TYhfA7cQAxKKACA3kMR\n\t2Ohw==","X-Gm-Message-State":"AHYfb5h1dX0nqivmzgMRwU8GUBvTgyCI+aaF0taDHrMYJFt2jqJo0xeU\n\tHi2YFl23OYzlmYJF","X-Received":"by 10.84.133.37 with SMTP id 34mr4974805plf.221.1503843781133;\n\tSun, 27 Aug 2017 07:23:01 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Daniel Borkmann , netdev@vger.kernel.org,\n\tast@kernel.org, tj@kernel.org, davem@davemloft.net","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<59A0D62F.3030806@iogearbox.net>","From":"David Ahern ","Message-ID":"<819aab80-b898-9eb8-36e2-759d2addca0d@gmail.com>","Date":"Sun, 27 Aug 2017 08:22:59 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<59A0D62F.3030806@iogearbox.net>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758268,"web_url":"http://patchwork.ozlabs.org/comment/1758268/","msgid":"","list_archive_url":null,"date":"2017-08-27T14:49:23","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/25/17 8:49 PM, Alexei Starovoitov wrote:\n> \n>> +\tif (prog && curr_recursive && !new_recursive)\n>> +\t\t/* if a parent has recursive prog attached, only\n>> +\t\t * allow recursive programs in descendent cgroup\n>> +\t\t */\n>> +\t\treturn -EINVAL;\n>> +\n>> \told_prog = cgrp->bpf.prog[type];\n> \n> ... I'm struggling to completely understand how it interacts\n> with BPF_F_ALLOW_OVERRIDE.\n\nThe 2 flags are completely independent. The existing override logic is\nunchanged. If a program can not be overridden, then the new recursive\nflag is irrelevant.\n\n> By default we shouldn't allow overriding, so if default prog attached\n> to a root, what happens if we try to attach F_RECURSIVE to a descendent?\n> If I'm reading the code correctly it will not succeed, which is good.\n> Could you add such scenario as test to test_cgrp2_attach2.c ?\n\nPatch 7 adds test cases to cover scenarios. I will add more tests per\ncomments below and rename to convey it tests the recursive flag.\n\n> \n> Now say we attach overridable and !recursive to a root, another\n> recursive prog will not be attached to a descedent, which is correct.\n\nyes\n\n> \n> But if we attach !overridable + recursive to a root we cannot attach\n> anything to a descendent right? Then why allow such combination at all?\n\nSure, we can not allow that combination to prevent the inefficiency of\nrecursively running through cgroups to run the base program.\n\n> So only overridable + recursive combination makes sense, right?\n> \n> I think all these combinations must be documented and tests must be\n> added. Sooner or later people will build security sensitive environment\n> with it and we have to meticulous now.\n\nIntentions below. I'll add more test cases to verify intentions agree\nwith code.\n\n> \n> Do you think it would make sense to split this patch out and\n> push patches 2 and 3 with few tests in parallel, while we're review\n> this change?\n\nI thought about that but decided no. The 'ip vrf exec' use case would\nbreak right of the gate if the other settings were used.\n\n> \n> Tejun needs to take a deep look into this patch as well.\n> \n\nThis is the intended behavior:\n\nThe override flag is independent of the recursive flag. If the override\nflag does not allow an override, the attempt to add a new program fails.\nThe recursive flag brings an additional constraint: once a cgroup has a\nprogram with the recursive flag set it is inherited by all descendant\ngroups. Attempts to insert a program that changes that flag fails EINVAL.\n\nStart with the root group at $MNT. No program is attached. By default\noverride is allowed and recursive is not set.\n\n1. Group $MNT/a is created.\n\ni. Default settings from $MNT are inherited; 'a' has override enabled\nand recursive disabled.\n\nii. Program is attached. Override flag is set, recursive flag is not set.\n\niii. Process in 'a' opens a socket, program attached to 'a' is run.\n\n\n2. $MNT/a/b is created\n\ni. 'b' inherits the program and settings of 'a' (override enabled,\nrecursive disabled).\n\nii. Process in 'b' opens a socket. Program inherited from 'a' is run.\n\niii. Non-interesting case for this patch set: attaching a non-recursive\nprogram to 'b' overrides the inherited one. process opens a socket only\nthe 'b' program is run.\n\niv. Program is attached to 'b', override flag set, recursive flag set.\n\nv. Process in 'b' opens a socket. Program attached to 'b' is run and\nthen program from 'a' is run. Recursion stops here since 'a' does not\nhave the recursion flag set.\n\n\n3. $MNT/a/b/c is created\n\ni. 'c' inherits the settings of 'b' (override is allowed, recursive flag\nis set)\n\nii. Process in 'c' opens a socket. No program from 'c' exists, so\nnothing is run. Recursion flag is set, so program from 'b' is run, then\nprogram from 'a' is run. Stop (recursive flag not set on 'a').\n\niii. Attaching a non-recursive program to 'c' fails because it inherited\nthe recursive flag from 'b' and that can not be reset by a descendant.\n\niv. Recursive program is attached to 'c'\n\nv. Process in 'c' opens a socket. Program attached to 'c' is run, then\nthe program from 'b' and the program from 'a'. Stop.\n\netc.\n\nTo consider what happens on doubling back and changing programs in the\nhierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\nrecursive on 'b' and recursive on 'c') for each of the following cases:\n\n1. Program attached to 'b' is detached, recursive flag is reset in the\nrequest. Attempt fails EINVAL because the recursion flag has to be set.\n\n\n2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n\nProcess in 'b' opens a socket. No program attached to 'b' so no program\nis run. Recursive flag is set to program from 'a' is run. Stop.\n\nWe should allow the recursive flag to be reset if the parent is not\nrecursive allowing an unwind of settings applied. I'll add that change.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"G+lfzHwd\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xgHqG5cTyz9sD9\n\tfor ;\n\tMon, 28 Aug 2017 00:49:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751183AbdH0OtZ (ORCPT );\n\tSun, 27 Aug 2017 10:49:25 -0400","from mail-pf0-f181.google.com ([209.85.192.181]:34872 \"EHLO\n\tmail-pf0-f181.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751132AbdH0OtY (ORCPT\n\t); Sun, 27 Aug 2017 10:49:24 -0400","by mail-pf0-f181.google.com with SMTP id c15so8808887pfm.2\n\tfor ; Sun, 27 Aug 2017 07:49:24 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:c1bc:2493:e932:bac3])\n\tby smtp.googlemail.com with ESMTPSA id\n\ts11sm17787976pgr.53.2017.08.27.07.49.23\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSun, 27 Aug 2017 07:49:23 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=f8e9WlMJ2Ck6P2JtQ/tjUlPiPeVc8ZRDKh/W8+ExeNA=;\n\tb=G+lfzHwdvntqBURqYvqvtIognVbdiEmx2z50/jytMOnjZ3ndJpTOplMDBQYu3K68f5\n\t0j26JCZaE16aBgqGLE5ZpvGq366xtuL9BUWJEe178t/edD9eXpkSk26ashLlShB0gPFg\n\tB/ZeOffRl3E0MbCLWM5wafi9iUQ7jh00KAxb02CYaX1xG9mRBlbintiYFc7LoLOZjZXR\n\t2HN/fngYrgag551eQchOUdxmIF9drVQsAbgzicUiO89+UgejFucA/gZ2oAi8OoohBtlD\n\tICRzJto+qwM+PGlQstckaLIHr9Z4yRSypXOlDy50zhvQKilRa4cnFAyELwDr1WLlMlSZ\n\tSf8w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=f8e9WlMJ2Ck6P2JtQ/tjUlPiPeVc8ZRDKh/W8+ExeNA=;\n\tb=dBG989Vxc8yievhg4EFxCKV6nRBAvBHv6OosntFuwOkRTSbLoJrVsPWv6NX58AnyhL\n\tnQN8zeuqvLo2RXnrucVuAcXaZS3xjP3gITz7W6TiFIR/h7PhrkZOF4pMhLr3WXSqq0LG\n\tO5Pb8S9rmy9ALCbOo79F9XQmhXhZpDC82I8LNG7ouYfhxwrvdo11+0ivD+Qeoqn8ugb2\n\tEd/AM3bjxulUXefGSxcQCt5/oKpxiTgnYy3rhx3b0Yoy7xN+UPWz+ucxuUvWR+Hp0MgK\n\tBG5Rrlr3LbnzQ03XZM62veCv+6AvSLm5dALPy1I0s99qYjQipCJzirADMFvVhrek+v3w\n\t+1ag==","X-Gm-Message-State":"AHYfb5g/jHeSy/t/v0awCE0dUofNGpH7Qq4Ia7CGO8YNpwTuJBYsGeh6\n\tnqpIpzfaFTwE3A==","X-Received":"by 10.84.232.197 with SMTP id x5mr5158254plm.18.1503845364273;\n\tSun, 27 Aug 2017 07:49:24 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Alexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net,\n\t\"David Ahern (gmail)\" ","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>","From":"David Ahern ","Message-ID":"","Date":"Sun, 27 Aug 2017 08:49:23 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170826024957.m5ita6usxihywmdd@ast-mbp>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758945,"web_url":"http://patchwork.ozlabs.org/comment/1758945/","msgid":"<20170828235653.jq62menrcfrh5rco@ast-mbp>","list_archive_url":null,"date":"2017-08-28T23:56:55","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n> \n> The override flag is independent of the recursive flag. If the override\n> flag does not allow an override, the attempt to add a new program fails.\n> The recursive flag brings an additional constraint: once a cgroup has a\n> program with the recursive flag set it is inherited by all descendant\n> groups. Attempts to insert a program that changes that flag fails EINVAL.\n> \n> Start with the root group at $MNT. No program is attached. By default\n> override is allowed and recursive is not set.\n\nThe above explanation is the reason we need tests for this logic.\nThe default is the opposite! By default override is _not_ allowed.\n\n> 1. Group $MNT/a is created.\n> \n> i. Default settings from $MNT are inherited; 'a' has override enabled\n> and recursive disabled.\n\nnot true, but say the user attached a prog wih override on...\n\n> ii. Program is attached. Override flag is set, recursive flag is not set.\n> \n> iii. Process in 'a' opens a socket, program attached to 'a' is run.\n> \n> \n> 2. $MNT/a/b is created\n> \n> i. 'b' inherits the program and settings of 'a' (override enabled,\n> recursive disabled).\n> \n> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.\n> \n> iii. Non-interesting case for this patch set: attaching a non-recursive\n> program to 'b' overrides the inherited one. process opens a socket only\n> the 'b' program is run.\n>\n> iv. Program is attached to 'b', override flag set, recursive flag set.\n> \n> v. Process in 'b' opens a socket. Program attached to 'b' is run and\n> then program from 'a' is run. Recursion stops here since 'a' does not\n> have the recursion flag set.\n\nisn't this the problem? Override+non_recurse was set on 'a'.\nNow we attached override+recurse on 'b' and suddenly 'a'\nwill be run like it was 'recursive'?\nimo that is counter intuitive to the owner of 'a'.\nI think there can be two options:\n- if recurse is not set on 'a', all of it descendents should not be allowed\n to use recurse flag\n- if recurse is not set on 'a', it should not be run\n\nimo the former is cleaner and avoids issues with detach in the middle\n\n> 3. $MNT/a/b/c is created\n> \n> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag\n> is set)\n> \n> ii. Process in 'c' opens a socket. No program from 'c' exists, so\n> nothing is run. Recursion flag is set, so program from 'b' is run, then\n> program from 'a' is run. Stop (recursive flag not set on 'a').\n\nalso doesn't make sense to me. Both 'b' and 'c' were attached as\noverride+recurse while 'a' as non-recurse why would it run?\nThe owner of 'a' attached it as override in the first place,\nso it assumed that if descendent wants to override it it can\nand the prog 'a' won't be running.\n\n> iii. Attaching a non-recursive program to 'c' fails because it inherited\n> the recursive flag from 'b' and that can not be reset by a descendant.\n\nthat part makes sense\n\n> iv. Recursive program is attached to 'c'\n> \n> v. Process in 'c' opens a socket. Program attached to 'c' is run, then\n> the program from 'b' and the program from 'a'. Stop.\n> \n> etc.\n> \n> To consider what happens on doubling back and changing programs in the\n> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\n> recursive on 'b' and recursive on 'c') for each of the following cases:\n> \n> 1. Program attached to 'b' is detached, recursive flag is reset in the\n> request. Attempt fails EINVAL because the recursion flag has to be set.\n\ndidn't get this point. you mean 'detach' will fail?\n\n> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n\nmeaing that detach from 'b' has to pass recurse flag to be detached?\nThat's also odd.\nimo detach should always succeed and the process doing detach\nshouldn't need to know what flags were used in attach.\n\n> Process in 'b' opens a socket. No program attached to 'b' so no program\n> is run. Recursive flag is set to program from 'a' is run. Stop.\n> \n> We should allow the recursive flag to be reset if the parent is not\n> recursive allowing an unwind of settings applied. I'll add that change.\n\nI don't get this part.\nAnyway looking forward to the next patch set with tests and comments like above.\n\nAlso adding Andy to cc. I'd really like both Andy and Tejun to review this logic.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"PU0z0o/Z\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xh7wg5CPfz9s83\n\tfor ;\n\tTue, 29 Aug 2017 09:57:07 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751215AbdH1X5A (ORCPT );\n\tMon, 28 Aug 2017 19:57:00 -0400","from mail-pf0-f194.google.com ([209.85.192.194]:33755 \"EHLO\n\tmail-pf0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751194AbdH1X47 (ORCPT\n\t); Mon, 28 Aug 2017 19:56:59 -0400","by mail-pf0-f194.google.com with SMTP id c28so1227893pfe.0\n\tfor ; Mon, 28 Aug 2017 16:56:58 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:2457])\n\tby smtp.gmail.com with ESMTPSA id\n\tv11sm2081121pgo.39.2017.08.28.16.56.56\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 28 Aug 2017 16:56:57 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=Ko/cJuhrKQyK11Mub0H/K6IAbUCDpj+X6z62uvjpjlE=;\n\tb=PU0z0o/ZpvlXXXNdcmRIY0Ze/y4JHVteM6t7eH+IeBqQgsvlUkJi3Pb8/yl0v+cyNJ\n\t3OCISUnwbDZXJZLhfJHQjaKC3EPJlCzTFHTZBEEcb+4nFhm8j+olbD7bonnr767dpYfT\n\tUoNd6R1MA0qaveFSRDDbRvflAZ8TqKq7TqgcBAKg6GW5+C/LWeIi1lYowaWrqkDB+RBA\n\tWRcfL/o+MSVjCHPUIn26FUvK/AlI0FX/HhcP10SLvi8nx/IwQJIwwGX+6rRUfGqR/M10\n\t2hidcj/bRVYJzzlB1GTHy45NV1rhZKBqwGeCEWeAaebLv5OMTCMDO3feeMvlJhTuE5+G\n\tj6FQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=Ko/cJuhrKQyK11Mub0H/K6IAbUCDpj+X6z62uvjpjlE=;\n\tb=PWC4visNe3V8dw0fCfqE9JDlwnUa7nQGRUxV8zZT9caQmo3TzEtsRrh+rt2/dPZrZG\n\tYzQ/Imq5Xh92/0Ug/R0j9AyHng9XDTk6StWFHUUdvbJ9lHfDVAhWxWgkyl7S5W2Hx0Z8\n\tZewL5wZWPrCvVEu1O8PGiY0q8qrH9jht6f9G/4SRiHRCFmbVH9fwNo4zLljd1TJdFgFH\n\t1+eP3wQ/xJXychNgkTxREXueVDPObSDID9+sCcVjdQZ7nCxHoxxhXHS1a16tBMiltSNS\n\tuXT9O91SiGSb2tTXeG1YJchLbALsk+sEqfWFx4APRkGTp/WerqJkgiGpe06w8O+1BBqB\n\t11SQ==","X-Gm-Message-State":"AHYfb5hkAMDdU3JnPAIVHzcqZor7SqwWLherLiMFJkWZpnMIK7ELwobT\n\toevjIiOmU1DeTMTt0D0=","X-Received":"by 10.98.62.130 with SMTP id y2mr2140069pfj.167.1503964618473;\n\tMon, 28 Aug 2017 16:56:58 -0700 (PDT)","Date":"Mon, 28 Aug 2017 16:56:55 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170828235653.jq62menrcfrh5rco@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758960,"web_url":"http://patchwork.ozlabs.org/comment/1758960/","msgid":"<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>","list_archive_url":null,"date":"2017-08-29T00:43:42","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/28/17 5:56 PM, Alexei Starovoitov wrote:\n> On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n>>\n>> The override flag is independent of the recursive flag. If the override\n>> flag does not allow an override, the attempt to add a new program fails.\n>> The recursive flag brings an additional constraint: once a cgroup has a\n>> program with the recursive flag set it is inherited by all descendant\n>> groups. Attempts to insert a program that changes that flag fails EINVAL.\n>>\n>> Start with the root group at $MNT. No program is attached. By default\n>> override is allowed and recursive is not set.\n> \n> The above explanation is the reason we need tests for this logic.\n> The default is the opposite! By default override is _not_ allowed.\n\nyes, I got that backwards. It's how my programs work since I always add\nthe OVERRIDE flag ATM.\n\n> \n>> 1. Group $MNT/a is created.\n>>\n>> i. Default settings from $MNT are inherited; 'a' has override enabled\n>> and recursive disabled.\n> \n> not true, but say the user attached a prog wih override on...\n\nexactly.\n\n> \n>> ii. Program is attached. Override flag is set, recursive flag is not set.\n>>\n>> iii. Process in 'a' opens a socket, program attached to 'a' is run.\n>>\n>>\n>> 2. $MNT/a/b is created\n>>\n>> i. 'b' inherits the program and settings of 'a' (override enabled,\n>> recursive disabled).\n>>\n>> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.\n>>\n>> iii. Non-interesting case for this patch set: attaching a non-recursive\n>> program to 'b' overrides the inherited one. process opens a socket only\n>> the 'b' program is run.\n>>\n>> iv. Program is attached to 'b', override flag set, recursive flag set.\n>>\n>> v. Process in 'b' opens a socket. Program attached to 'b' is run and\n>> then program from 'a' is run. Recursion stops here since 'a' does not\n>> have the recursion flag set.\n> \n> isn't this the problem? Override+non_recurse was set on 'a'.\n> Now we attached override+recurse on 'b' and suddenly 'a'\n> will be run like it was 'recursive'?\n\nWithout 'b', 'a' is run. With 'b' and the recurse flag I am suggesting\nthe user is saying I want 'b' and then 'a'. ie., the first parent group\nwithout the flag is where we stop.\n\n> imo that is counter intuitive to the owner of 'a'.\n> I think there can be two options:\n> - if recurse is not set on 'a', all of it descendents should not be allowed\n> to use recurse flag\n> - if recurse is not set on 'a', it should not be run\n\nIf 'a' can be overridden then I don't agree with the first suggestion.\nWhich means you are suggesting we stop at the last group with the\nrecursive flag set. That is fine too.\n\n> \n> imo the former is cleaner and avoids issues with detach in the middle\n> \n>> 3. $MNT/a/b/c is created\n>>\n>> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag\n>> is set)\n>>\n>> ii. Process in 'c' opens a socket. No program from 'c' exists, so\n>> nothing is run. Recursion flag is set, so program from 'b' is run, then\n>> program from 'a' is run. Stop (recursive flag not set on 'a').\n> \n> also doesn't make sense to me. Both 'b' and 'c' were attached as\n> override+recurse while 'a' as non-recurse why would it run?\n> The owner of 'a' attached it as override in the first place,\n> so it assumed that if descendent wants to override it it can\n> and the prog 'a' won't be running.\n\nsame argument as above - the question is where do we stop. My suggestion\nand implementation is stopping at the first group without the flag.\n\nAs stated all along, descendant groups inherit programs of the parent\nmarked recurse - not by copying them into the group but by recursion.\n\n\n> \n>> iii. Attaching a non-recursive program to 'c' fails because it inherited\n>> the recursive flag from 'b' and that can not be reset by a descendant.\n> \n> that part makes sense\n> \n>> iv. Recursive program is attached to 'c'\n>>\n>> v. Process in 'c' opens a socket. Program attached to 'c' is run, then\n>> the program from 'b' and the program from 'a'. Stop.\n>>\n>> etc.\n>>\n>> To consider what happens on doubling back and changing programs in the\n>> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\n>> recursive on 'b' and recursive on 'c') for each of the following cases:\n>>\n>> 1. Program attached to 'b' is detached, recursive flag is reset in the\n>> request. Attempt fails EINVAL because the recursion flag has to be set.\n> \n> didn't get this point. you mean 'detach' will fail?\n\nYes, because it tried to reset the flag in the process.\n\nThis is something we can make user friendly - the detach succeeds, but\nthe recurse flag is ignored and the recurse flag in the group is not\nreset unless it is the base group with the recurse flag (i.e., the\nparent is marked non-recurse).\n\n\n> \n>> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n> \n> meaing that detach from 'b' has to pass recurse flag to be detached?\n> That's also odd.\n> imo detach should always succeed and the process doing detach\n> shouldn't need to know what flags were used in attach.\n\nThen, we agree to make it user friendly and handle resetting the recurse\nflag automatically.\n\n> \n>> Process in 'b' opens a socket. No program attached to 'b' so no program\n>> is run. Recursive flag is set to program from 'a' is run. Stop.\n>>\n>> We should allow the recursive flag to be reset if the parent is not\n>> recursive allowing an unwind of settings applied. I'll add that change.\n> \n> I don't get this part.\n> Anyway looking forward to the next patch set with tests and comments like above.\n\nPer above discussion, you don't want 'a' run since it is not marked\nrecurse. My last sentence is the user friendly part in resetting the\nflag in the cgroup.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"vVNju04W\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xh8yY2T9lz9s7M\n\tfor ;\n\tTue, 29 Aug 2017 10:43:49 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751231AbdH2Anq (ORCPT );\n\tMon, 28 Aug 2017 20:43:46 -0400","from mail-pg0-f65.google.com ([74.125.83.65]:35028 \"EHLO\n\tmail-pg0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751209AbdH2Anp (ORCPT\n\t); Mon, 28 Aug 2017 20:43:45 -0400","by mail-pg0-f65.google.com with SMTP id r133so1500351pgr.2\n\tfor ; Mon, 28 Aug 2017 17:43:45 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:c1bc:2493:e932:bac3])\n\tby smtp.googlemail.com with ESMTPSA id\n\tb29sm2751914pfh.22.2017.08.28.17.43.43\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 28 Aug 2017 17:43:44 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=KWYQPHm0Bs1v0JsX1wlhpXP/BgT9tWj1e4XK1bNYXNY=;\n\tb=vVNju04Wl1q9VO6lBTY7Oc1ENSXfVD79ZFQfusxNO0QrqxeHhzE1t9OjXR5uBtyz61\n\trLVk8SPwtcwdDZ/E8bNbHYQnznsN4BTyxfKqB6LDu86OLETk2DBLS5/bVbfk9Sf02lI3\n\tzMzQECT0IyTVWSKmYlXAwnO1bb4wUgW97srwR3pjVNQdi2zEXv8xQ0asr5gJN14mgYb5\n\tzDKRhVRmBRePNoXPMZrwifLnYJLnoB61pLkJyC2wjKySuDztZzlln+S4Mt3aodPoM+Ui\n\t7Inobi3nYuJUeA+0ZCtDlHvE/T8lkQqQ9+GU56kdAxwhJfsmObjCstINCsmlGGckfE0V\n\tzb3A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=KWYQPHm0Bs1v0JsX1wlhpXP/BgT9tWj1e4XK1bNYXNY=;\n\tb=cG/HIKx/64MXUxta5Es9UimCd94446vdwjeQlia7BD1gX2G6nZSO3z6jgvVwTxVpop\n\toL3TAwpfmMGm6fhX4ZB5/AsurOHokpF7IUux4GkjqxWjvXkvWY11CGDzA30ZF79+dBN4\n\tWizM2fA3pK3B7owS5KW+MuFz1eNbcBRoFW09o8ZL7A8TZd/gpYOHN9L/odetcD3Tmaxa\n\tZQo1Pb5t2sdseowRzRTQh+3dmF46mZ3jDHl2lTVEJ4O8triaAjKcwqcgt6E5LuOgNXF1\n\tk9V/ZwZUsSz0vLj+H1Kr4Nr9Kb3hqR9I3FW2vnOFfgWvNHSiC8GttyuVw+/lM/dE2GZX\n\tiLzA==","X-Gm-Message-State":"AHYfb5i+fGvRz5zO2zFjFozaiI7JtHZjcMsYW/ekq75Ht5TNkbRJyis5\n\tZIHDdWCyC09dBg==","X-Received":"by 10.99.109.12 with SMTP id i12mr2234508pgc.269.1503967424714; \n\tMon, 28 Aug 2017 17:43:44 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Alexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>","From":"David Ahern ","Message-ID":"<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>","Date":"Mon, 28 Aug 2017 18:43:42 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170828235653.jq62menrcfrh5rco@ast-mbp>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758967,"web_url":"http://patchwork.ozlabs.org/comment/1758967/","msgid":"<20170829011213.suddt5hkptaxd4rp@ast-mbp>","list_archive_url":null,"date":"2017-08-29T01:12:15","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Mon, Aug 28, 2017 at 06:43:42PM -0600, David Ahern wrote:\n> On 8/28/17 5:56 PM, Alexei Starovoitov wrote:\n> > On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n> >>\n> >> The override flag is independent of the recursive flag. If the override\n> >> flag does not allow an override, the attempt to add a new program fails.\n> >> The recursive flag brings an additional constraint: once a cgroup has a\n> >> program with the recursive flag set it is inherited by all descendant\n> >> groups. Attempts to insert a program that changes that flag fails EINVAL.\n> >>\n> >> Start with the root group at $MNT. No program is attached. By default\n> >> override is allowed and recursive is not set.\n> > \n> > The above explanation is the reason we need tests for this logic.\n> > The default is the opposite! By default override is _not_ allowed.\n> \n> yes, I got that backwards. It's how my programs work since I always add\n> the OVERRIDE flag ATM.\n> \n> > \n> >> 1. Group $MNT/a is created.\n> >>\n> >> i. Default settings from $MNT are inherited; 'a' has override enabled\n> >> and recursive disabled.\n> > \n> > not true, but say the user attached a prog wih override on...\n> \n> exactly.\n> \n> > \n> >> ii. Program is attached. Override flag is set, recursive flag is not set.\n> >>\n> >> iii. Process in 'a' opens a socket, program attached to 'a' is run.\n> >>\n> >>\n> >> 2. $MNT/a/b is created\n> >>\n> >> i. 'b' inherits the program and settings of 'a' (override enabled,\n> >> recursive disabled).\n> >>\n> >> ii. Process in 'b' opens a socket. Program inherited from 'a' is run.\n> >>\n> >> iii. Non-interesting case for this patch set: attaching a non-recursive\n> >> program to 'b' overrides the inherited one. process opens a socket only\n> >> the 'b' program is run.\n> >>\n> >> iv. Program is attached to 'b', override flag set, recursive flag set.\n> >>\n> >> v. Process in 'b' opens a socket. Program attached to 'b' is run and\n> >> then program from 'a' is run. Recursion stops here since 'a' does not\n> >> have the recursion flag set.\n> > \n> > isn't this the problem? Override+non_recurse was set on 'a'.\n> > Now we attached override+recurse on 'b' and suddenly 'a'\n> > will be run like it was 'recursive'?\n> \n> Without 'b', 'a' is run. With 'b' and the recurse flag I am suggesting\n> the user is saying I want 'b' and then 'a'. ie., the first parent group\n> without the flag is where we stop.\n> \n> > imo that is counter intuitive to the owner of 'a'.\n> > I think there can be two options:\n> > - if recurse is not set on 'a', all of it descendents should not be allowed\n> > to use recurse flag\n> > - if recurse is not set on 'a', it should not be run\n> \n> If 'a' can be overridden then I don't agree with the first suggestion.\n> Which means you are suggesting we stop at the last group with the\n> recursive flag set. That is fine too.\n> \n> > \n> > imo the former is cleaner and avoids issues with detach in the middle\n> > \n> >> 3. $MNT/a/b/c is created\n> >>\n> >> i. 'c' inherits the settings of 'b' (override is allowed, recursive flag\n> >> is set)\n> >>\n> >> ii. Process in 'c' opens a socket. No program from 'c' exists, so\n> >> nothing is run. Recursion flag is set, so program from 'b' is run, then\n> >> program from 'a' is run. Stop (recursive flag not set on 'a').\n> > \n> > also doesn't make sense to me. Both 'b' and 'c' were attached as\n> > override+recurse while 'a' as non-recurse why would it run?\n> > The owner of 'a' attached it as override in the first place,\n> > so it assumed that if descendent wants to override it it can\n> > and the prog 'a' won't be running.\n> \n> same argument as above - the question is where do we stop. My suggestion\n> and implementation is stopping at the first group without the flag.\n> \n> As stated all along, descendant groups inherit programs of the parent\n> marked recurse - not by copying them into the group but by recursion.\n> \n> \n> > \n> >> iii. Attaching a non-recursive program to 'c' fails because it inherited\n> >> the recursive flag from 'b' and that can not be reset by a descendant.\n> > \n> > that part makes sense\n> > \n> >> iv. Recursive program is attached to 'c'\n> >>\n> >> v. Process in 'c' opens a socket. Program attached to 'c' is run, then\n> >> the program from 'b' and the program from 'a'. Stop.\n> >>\n> >> etc.\n> >>\n> >> To consider what happens on doubling back and changing programs in the\n> >> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\n> >> recursive on 'b' and recursive on 'c') for each of the following cases:\n> >>\n> >> 1. Program attached to 'b' is detached, recursive flag is reset in the\n> >> request. Attempt fails EINVAL because the recursion flag has to be set.\n> > \n> > didn't get this point. you mean 'detach' will fail?\n> \n> Yes, because it tried to reset the flag in the process.\n> \n> This is something we can make user friendly - the detach succeeds, but\n> the recurse flag is ignored and the recurse flag in the group is not\n> reset unless it is the base group with the recurse flag (i.e., the\n> parent is marked non-recurse).\n\nif we don't reset group flags to default it will be even more difficult\nfor users to use, since attach with recursive flag + immediate detach sets\nsome internal flag on the cgroup and user space has no way of\neither querying this flag or deleting it.\n\n> > \n> >> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n> > \n> > meaing that detach from 'b' has to pass recurse flag to be detached?\n> > That's also odd.\n> > imo detach should always succeed and the process doing detach\n> > shouldn't need to know what flags were used in attach.\n> \n> Then, we agree to make it user friendly and handle resetting the recurse\n> flag automatically.\n\nin that sense yes attach/delete pair should be side-effect free.\n\n> >> Process in 'b' opens a socket. No program attached to 'b' so no program\n> >> is run. Recursive flag is set to program from 'a' is run. Stop.\n> >>\n> >> We should allow the recursive flag to be reset if the parent is not\n> >> recursive allowing an unwind of settings applied. I'll add that change.\n> > \n> > I don't get this part.\n> > Anyway looking forward to the next patch set with tests and comments like above.\n> \n> Per above discussion, you don't want 'a' run since it is not marked\n> recurse. My last sentence is the user friendly part in resetting the\n> flag in the cgroup.\n\nI'm still not grasping fully the semantics of what you're proposing.\nYou keep saying that override and recurse flags are indepedent, but\nthe more we talk the more it's clear that there is a complicated\nrelationship between them. Like no_override overrules everything, etc.\nI'm looking for the simplest to use logic. Not implementation.\nImplementation can be complex, but uapi should be as simple to\nexplain and as simple to understand as possible.\nSo how about allowing recurse+overide combination only?\nAll descendents must be recurse+override too and\nno program allowed to be set on parent unless it's recurse+override\nas well. Then detach anywhere is simple, since all programs in\nsuch chain are always recurse+override.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"T23nXhGx\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xh9bV1bLnz9sP5\n\tfor ;\n\tTue, 29 Aug 2017 11:12:22 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751319AbdH2BMT (ORCPT );\n\tMon, 28 Aug 2017 21:12:19 -0400","from mail-pf0-f196.google.com ([209.85.192.196]:33086 \"EHLO\n\tmail-pf0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751236AbdH2BMS (ORCPT\n\t); Mon, 28 Aug 2017 21:12:18 -0400","by mail-pf0-f196.google.com with SMTP id c28so1317927pfe.0\n\tfor ; Mon, 28 Aug 2017 18:12:18 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:2457])\n\tby smtp.gmail.com with ESMTPSA id\n\tf69sm2313875pfc.125.2017.08.28.18.12.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 28 Aug 2017 18:12:17 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=Z6X0Q8aej6s5vlE9uH/FXq/B3/t9/Jh5OHzBjhWIR20=;\n\tb=T23nXhGxI2Fyb41SL5R1Ra8Gysl5ZNbcbzoRJ4eFRlgwydSOBOtS5xnLWH/00X7xjE\n\tlhg8lkXN/Y+QlPPwC+AOv61/z5tKVSIS4x6HNRzJgjzM7EtagcZvwdk/2a78ME4AYVD7\n\txLk6hdS1F7izkK2X1OuAuQp/+gqxnYb6I0y1GW7y78upkqla/TylK4GyJIAx2D+rEFbS\n\th8el5MgVtdlkKOhlmLvzMTbJNqrrujt4UwgAS2oAJrQsWQH5yQ6sNK54kdsiMnKHBevF\n\t9hUTMprOHTHxgRAQwXSSdIqi3iNdmizyUU7dPrXqzyrRABAsDbtGE+Tpm2KKuuzdjcPe\n\t0qLg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=Z6X0Q8aej6s5vlE9uH/FXq/B3/t9/Jh5OHzBjhWIR20=;\n\tb=CA0My4QRuZVtMP2OMTagrcN6/zuj9MpCXudfBksKyeXE6N28luItOWceZGIbAyMVfG\n\tPiyoSl8d5+rr95Lb0kgyT+hAtVCWMRlPJDJlowKNTSd5OvqScaOGhuRcJc4ErX4OlBq0\n\tKSr2ut5/X+L/mdiF1ct3v5NQyzmNtFyJfQTszhwE2YQwr5K/W5R0wdMfsSvflr8/dhcn\n\ttLge6Ys0jQTFPlPOxzZYy/oITiUM+Ao9WNz8idkrXr7v+FBM6uh/Y2uyL5G5HdUvEKlg\n\t/97xQ47o54ia1HPeGajs0CZGvqdMGjZPxZcKoIEMYds4mrA1fB/Gy3FeSvtFoxWquFIQ\n\tfYDw==","X-Gm-Message-State":"AHYfb5jcr2+tIpLaSpFUJV2hwnPz9jX1h4eA5deSayBJVbwDU9iTxeCJ\n\tJy+VlHcBl0u2wQ==","X-Received":"by 10.84.194.228 with SMTP id h91mr2906980pld.415.1503969138259; \n\tMon, 28 Aug 2017 18:12:18 -0700 (PDT)","Date":"Mon, 28 Aug 2017 18:12:15 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170829011213.suddt5hkptaxd4rp@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1758988,"web_url":"http://patchwork.ozlabs.org/comment/1758988/","msgid":"<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>","list_archive_url":null,"date":"2017-08-29T02:22:31","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/28/17 7:12 PM, Alexei Starovoitov wrote:\n>>>> To consider what happens on doubling back and changing programs in the\n>>>> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\n>>>> recursive on 'b' and recursive on 'c') for each of the following cases:\n>>>>\n>>>> 1. Program attached to 'b' is detached, recursive flag is reset in the\n>>>> request. Attempt fails EINVAL because the recursion flag has to be set.\n>>>\n>>> didn't get this point. you mean 'detach' will fail?\n>>\n>> Yes, because it tried to reset the flag in the process.\n>>\n>> This is something we can make user friendly - the detach succeeds, but\n>> the recurse flag is ignored and the recurse flag in the group is not\n>> reset unless it is the base group with the recurse flag (i.e., the\n>> parent is marked non-recurse).\n> \n> if we don't reset group flags to default it will be even more difficult\n> for users to use, since attach with recursive flag + immediate detach sets\n> some internal flag on the cgroup and user space has no way of\n> either querying this flag or deleting it.\n\nWe have discussed this before -- the need to know which cgroup has a\nprogram and now what is the status of flags. That need is a different\nproblem than this patch set.\n\nI'll address the reset of the flags below to keep that discussion together.\n\n> \n>>>\n>>>> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n>>>\n>>> meaing that detach from 'b' has to pass recurse flag to be detached?\n>>> That's also odd.\n>>> imo detach should always succeed and the process doing detach\n>>> shouldn't need to know what flags were used in attach.\n>>\n>> Then, we agree to make it user friendly and handle resetting the recurse\n>> flag automatically.\n> \n> in that sense yes attach/delete pair should be side-effect free.\n> \n>>>> Process in 'b' opens a socket. No program attached to 'b' so no program\n>>>> is run. Recursive flag is set to program from 'a' is run. Stop.\n>>>>\n>>>> We should allow the recursive flag to be reset if the parent is not\n>>>> recursive allowing an unwind of settings applied. I'll add that change.\n>>>\n>>> I don't get this part.\n>>> Anyway looking forward to the next patch set with tests and comments like above.\n>>\n>> Per above discussion, you don't want 'a' run since it is not marked\n>> recurse. My last sentence is the user friendly part in resetting the\n>> flag in the cgroup.\n> \n> I'm still not grasping fully the semantics of what you're proposing.\n> You keep saying that override and recurse flags are indepedent, but\n> the more we talk the more it's clear that there is a complicated\n> relationship between them. Like no_override overrules everything, etc.\n\nyes, I have said that a few times. Override should block everything in\nterms of installing programs. If it is not enabled, the status of the\nrecurse flag is not relevant at attach / detach time as the call should\nfail. So installing a program with the recurse flag only works if\noverride is allowed.\n\n\n> I'm looking for the simplest to use logic. Not implementation.\n> Implementation can be complex, but uapi should be as simple to\n> explain and as simple to understand as possible.\n> So how about allowing recurse+overide combination only?\n> All descendents must be recurse+override too and\n> no program allowed to be set on parent unless it's recurse+override\n> as well. Then detach anywhere is simple, since all programs in\n> such chain are always recurse+override.\n\n\nLet's walk through examples based on the new ground rule - recursion\nstops at last cgroup with flag set.\n\nAssuming override is allowed ...\n\n${MNT}/a/b/c/d\n\n- 'a' has no program\n\n- 'b' has a program, override allowed, recurse set\n\n- 'c' and 'd' inherit the program from 'b' by recursion, not inheritance\n(ie., bpf.effective is not updated with the program from 'b', but the\nrecurse flag is set on 'c' and 'd').\n\nAt this point 'c' and 'd' can ONLY take programs that are recursive.\n\n- 'c' gets a program installed\n- 'd' gets a program installed.\n\n\nProcess in 'd' has programs run in this order: 'd', 'c', 'b'\n\n\nNow, program 'c' is detached. It is in the middle of the recursive set.\nIt MUST keep the recurse flag set as it inherited the restriction from\n'b'. The recurse flag on 'c' can ONLY be reset when the program is\ndetached from 'b' as it is the start of the recursive chain.\n\nI'll stop here to make sure we agree on the above. Considering all\npermutations is a maze.\n\n###\n\nAlso, let's agree on this intention. Based on the new ground rule, I\nwant to point out this example:\n\nIf 'a' gets a program installed with no recurse flag set, ONLY processes\nin 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\nall stop at cgroup 'b' program.\n\nTo me this is counterintuitive and why I said programs are run up to the\nfirst parent without the recurse flag. They are all part of the same tree.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"T/ksCYGW\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhC8f0Ftgz9s7f\n\tfor ;\n\tTue, 29 Aug 2017 12:22:41 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751272AbdH2CWg (ORCPT );\n\tMon, 28 Aug 2017 22:22:36 -0400","from mail-pf0-f195.google.com ([209.85.192.195]:38100 \"EHLO\n\tmail-pf0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751209AbdH2CWe (ORCPT\n\t); Mon, 28 Aug 2017 22:22:34 -0400","by mail-pf0-f195.google.com with SMTP id r187so1403963pfr.5\n\tfor ; Mon, 28 Aug 2017 19:22:34 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:d89a:ab61:c4f1:b1cb])\n\tby smtp.googlemail.com with ESMTPSA id\n\tg191sm2220828pfc.164.2017.08.28.19.22.32\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 28 Aug 2017 19:22:33 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=y4+lw0gEr4DKJhS+9yMIemdu/VHpun9GUtepxKgd2rE=;\n\tb=T/ksCYGWcLD+GpTHGpTG7m03RLnl92rmoY1cVjODUMq+DR8a5i1IoMaJupTkeV5/JK\n\t2PxEzKuqas3jB8pqzAsYBf29qLCWpHBFIOTjN2Jz6O0dJEDxiI//co0xjTYZqtu4fbpl\n\tpwus8BibI2L7lmoLucbaXrtn6j65VynXOXvab/jdP5V63bDrS77bON9GJ8KYVHOLiEe+\n\tLgCsnCia482UQlGUG8U09dwjs6trpxgjJT8JgpEMvvKSuZJ2K6gEY5V5W8VFfqAibg+a\n\to4EKFvGOrE/Ej9wN0RNKbgxEuVq/VL92Y4lMbmGqOLzJ49EI7SEE5gIVlZELH0p2+mot\n\tis8Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=y4+lw0gEr4DKJhS+9yMIemdu/VHpun9GUtepxKgd2rE=;\n\tb=dnQSSL9KGRMBu2/N+hk1sKJM8I1WjVzjp0MBcBSdd1rdmDk7VrXBnYD9rSOkFI/Vno\n\t4Uh/Le2/3wJxdusLGyvKsTqYcWmHI6X9Bio+6FESdfoZs4U32WK6Gn3FwSCDDSYkkl7q\n\tWQA4gCHP0e3NUaHMk6f/eNtIW5hhHeHBuccVWxMB6Y6GeF9/xD+6WDdLvxP0L7T29eZ3\n\tpiBL8zAcCOfh3VkbZtV0XHHYiTEguIGbP+/v5qE2HCH3i5wJxYVG1rRskvJYLb2Uayfg\n\tOGPEpevFnKLCmMilYz8MoW/TXy8mB/TWAReYRwHa5iTCuCacBKbcd49yGDXznMFnIKhG\n\ta79w==","X-Gm-Message-State":"AHYfb5jvkxPIdD1eE73heWFaa5UHoUi9riiXe5T0XLh7qnCix5NDlpJW\n\tN0Mguto/FYXVyA==","X-Received":"by 10.84.224.72 with SMTP id a8mr3123457plt.92.1503973354249;\n\tMon, 28 Aug 2017 19:22:34 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Alexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net,\n\t\"David Ahern (gmail)\" ","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>","From":"David Ahern ","Message-ID":"<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>","Date":"Mon, 28 Aug 2017 20:22:31 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170829011213.suddt5hkptaxd4rp@ast-mbp>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759021,"web_url":"http://patchwork.ozlabs.org/comment/1759021/","msgid":"<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>","list_archive_url":null,"date":"2017-08-29T04:11:20","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Mon, Aug 28, 2017 at 08:22:31PM -0600, David Ahern wrote:\n> On 8/28/17 7:12 PM, Alexei Starovoitov wrote:\n> >>>> To consider what happens on doubling back and changing programs in the\n> >>>> hierarchy, start with $MNT/a/b/c from 3 above (non-recursive on 'a',\n> >>>> recursive on 'b' and recursive on 'c') for each of the following cases:\n> >>>>\n> >>>> 1. Program attached to 'b' is detached, recursive flag is reset in the\n> >>>> request. Attempt fails EINVAL because the recursion flag has to be set.\n> >>>\n> >>> didn't get this point. you mean 'detach' will fail?\n> >>\n> >> Yes, because it tried to reset the flag in the process.\n> >>\n> >> This is something we can make user friendly - the detach succeeds, but\n> >> the recurse flag is ignored and the recurse flag in the group is not\n> >> reset unless it is the base group with the recurse flag (i.e., the\n> >> parent is marked non-recurse).\n> > \n> > if we don't reset group flags to default it will be even more difficult\n> > for users to use, since attach with recursive flag + immediate detach sets\n> > some internal flag on the cgroup and user space has no way of\n> > either querying this flag or deleting it.\n> \n> We have discussed this before -- the need to know which cgroup has a\n> program and now what is the status of flags. That need is a different\n> problem than this patch set.\n> \n> I'll address the reset of the flags below to keep that discussion together.\n> \n> > \n> >>>\n> >>>> 2. Program attached to 'b' is detached, recursive flag is set. Allowed.\n> >>>\n> >>> meaing that detach from 'b' has to pass recurse flag to be detached?\n> >>> That's also odd.\n> >>> imo detach should always succeed and the process doing detach\n> >>> shouldn't need to know what flags were used in attach.\n> >>\n> >> Then, we agree to make it user friendly and handle resetting the recurse\n> >> flag automatically.\n> > \n> > in that sense yes attach/delete pair should be side-effect free.\n> > \n> >>>> Process in 'b' opens a socket. No program attached to 'b' so no program\n> >>>> is run. Recursive flag is set to program from 'a' is run. Stop.\n> >>>>\n> >>>> We should allow the recursive flag to be reset if the parent is not\n> >>>> recursive allowing an unwind of settings applied. I'll add that change.\n> >>>\n> >>> I don't get this part.\n> >>> Anyway looking forward to the next patch set with tests and comments like above.\n> >>\n> >> Per above discussion, you don't want 'a' run since it is not marked\n> >> recurse. My last sentence is the user friendly part in resetting the\n> >> flag in the cgroup.\n> > \n> > I'm still not grasping fully the semantics of what you're proposing.\n> > You keep saying that override and recurse flags are indepedent, but\n> > the more we talk the more it's clear that there is a complicated\n> > relationship between them. Like no_override overrules everything, etc.\n> \n> yes, I have said that a few times. Override should block everything in\n> terms of installing programs. If it is not enabled, the status of the\n> recurse flag is not relevant at attach / detach time as the call should\n> fail. So installing a program with the recurse flag only works if\n> override is allowed.\n> \n> \n> > I'm looking for the simplest to use logic. Not implementation.\n> > Implementation can be complex, but uapi should be as simple to\n> > explain and as simple to understand as possible.\n> > So how about allowing recurse+overide combination only?\n> > All descendents must be recurse+override too and\n> > no program allowed to be set on parent unless it's recurse+override\n> > as well. Then detach anywhere is simple, since all programs in\n> > such chain are always recurse+override.\n> \n> \n> Let's walk through examples based on the new ground rule - recursion\n> stops at last cgroup with flag set.\n> \n> Assuming override is allowed ...\n> \n> ${MNT}/a/b/c/d\n> \n> - 'a' has no program\n> \n> - 'b' has a program, override allowed, recurse set\n> \n> - 'c' and 'd' inherit the program from 'b' by recursion, not inheritance\n> (ie., bpf.effective is not updated with the program from 'b', but the\n> recurse flag is set on 'c' and 'd').\n> \n> At this point 'c' and 'd' can ONLY take programs that are recursive.\n> \n> - 'c' gets a program installed\n> - 'd' gets a program installed.\n> \n> \n> Process in 'd' has programs run in this order: 'd', 'c', 'b'\n> \n> \n> Now, program 'c' is detached. It is in the middle of the recursive set.\n> It MUST keep the recurse flag set as it inherited the restriction from\n> 'b'. The recurse flag on 'c' can ONLY be reset when the program is\n> detached from 'b' as it is the start of the recursive chain.\n> \n> I'll stop here to make sure we agree on the above. Considering all\n> permutations is a maze.\n\nAgree on the above, but you're mixing semantics of the new recurse\nflag and implementation of it. Ex: we don't have to copy this flag\nfrom prog->attr into cgroup. So this reset or non-reset discussion\nonly makes sense in the context of your current implementation.\nWe can implement the logic differently. Like don't copy that flag\nat all and at attach time walk parent->parent->parent and see\nwhat programs are attached. All of them should have prog->attr & recurse_bit set\nIn such implementation detach from 'b' is a nop from reset/non-reset\npoint of view. When socket creation in 'c' is invoked the program\n'c' is called first then the code keeps walking parents until root\ninvoking 'a' along the way.\nI'm not saying it will be an efficient implementation. The point\nis to discuss UAPI independent of implementation.\n\n> ###\n> \n> Also, let's agree on this intention. Based on the new ground rule, I\n> want to point out this example:\n> \n> If 'a' gets a program installed with no recurse flag set, ONLY processes\n> in 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\n> all stop at cgroup 'b' program.\n\nI'm proposing that such situation should not be allowed to happen.\nIn a->b->c->d cgroup scenario if override+recurse prog attached to 'b'\nthen only the same override+recurse can be attached to c, d, a.\nSo at detach time there can be gaps (like only 'b' and 'd' have\noverride+recurse progs), but walking up until root from any point\nwill guarantee that only override+recurse programs are seen.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"neRVfIUF\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhFZF2QpNz9t2V\n\tfor ;\n\tTue, 29 Aug 2017 14:11:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750909AbdH2EL0 (ORCPT );\n\tTue, 29 Aug 2017 00:11:26 -0400","from mail-pf0-f196.google.com ([209.85.192.196]:33388 \"EHLO\n\tmail-pf0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750779AbdH2ELZ (ORCPT\n\t); Tue, 29 Aug 2017 00:11:25 -0400","by mail-pf0-f196.google.com with SMTP id c28so1578215pfe.0\n\tfor ; Mon, 28 Aug 2017 21:11:24 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:2457])\n\tby smtp.gmail.com with ESMTPSA id\n\td17sm2793843pfj.23.2017.08.28.21.11.22\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 28 Aug 2017 21:11:23 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=n7NFJPeFhid2heEks8Ad1LtAVvE0Vy+0ufdLuHk8+eY=;\n\tb=neRVfIUFJZzxOKYTti6aQZRXy+qMbT9Kx3U+L9ZbYwFLka2AnORlT/Y9nWt205Vhi4\n\th1smR/Jm5JcG4a+O3QBs7/dlDGR7QotWX8h0VrwNnOhYL88nB+lZR7pod2835y1EaE3f\n\t7zBJ1W8mdNEg/xgH0UjlRK2ziCjJ9oLlBvJXNXYsTfziMRU2l/+hXq3lZyrHyh0pGXhE\n\tr32lVjX8sdcLw7QvVl508jMpnDfN5c15x8NEFzqPmXTVO1QVjPZvZ5HvPPfSsL08FOln\n\t3xoSd89o8lRdcHv0dkvG9vQAwhekegtlY25pu7hNEE5HfXHMoGyzfzeUkyBWaE/WMpTO\n\thhaQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=n7NFJPeFhid2heEks8Ad1LtAVvE0Vy+0ufdLuHk8+eY=;\n\tb=jXdqqWR+Ds5FbzPteBcwPDhIP3fxLdOMA5GJUiAOXhu5cyODnQ3To53ssJxE+flcfn\n\tvTTldhB8CUK3cEP/BEFTcIFB1kHPZprqQ1/rYfX1tykchqrVBl5zL6Kg7TYrcQV3Vd/z\n\tI1MjFTAcilsrcyHNN0c5RPKly9IwJo2T9mNvCqe85NRnV+HTnKbfSFLCy/nl9/Vx3Xcj\n\tqf7Atruc45Fb91ZfW6+xMQd2hD/D7kT/HTOqPXzxGeU/Za3lvrd9T8vzT6QPH76Sfyjr\n\tUR0Jt3oiBsWZ4JQjKq026Hr0J35v5mtqu5fUJQOwOv7RgLeRoM1uK5J/WMrFU0HyG6RF\n\tJyAA==","X-Gm-Message-State":"AHYfb5gpNSXgifJcfPEfHRYpQPyKU3bXJyYsluBXhd9ina+mEwXq7m/s\n\tXKDwdisArtNM6g==","X-Received":"by 10.99.181.4 with SMTP id y4mr2639880pge.327.1503979884263;\n\tMon, 28 Aug 2017 21:11:24 -0700 (PDT)","Date":"Mon, 28 Aug 2017 21:11:20 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>\n\t<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759790,"web_url":"http://patchwork.ozlabs.org/comment/1759790/","msgid":"","list_archive_url":null,"date":"2017-08-30T01:03:43","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/28/17 10:11 PM, Alexei Starovoitov wrote:\n> \n> Agree on the above, but you're mixing semantics of the new recurse\n> flag and implementation of it. Ex: we don't have to copy this flag\n> from prog->attr into cgroup. So this reset or non-reset discussion\n> only makes sense in the context of your current implementation.\n> We can implement the logic differently. Like don't copy that flag\n> at all and at attach time walk parent->parent->parent and see\n> what programs are attached. All of them should have prog->attr & recurse_bit set\n> In such implementation detach from 'b' is a nop from reset/non-reset\n> point of view. When socket creation in 'c' is invoked the program\n> 'c' is called first then the code keeps walking parents until root\n> invoking 'a' along the way.\n\nSo you are suggesting there is no recursive flag per cgroup? How do you\nknow you need to walk cgroups? How do you know when to stop running\nprograms?\n\n> I'm not saying it will be an efficient implementation. The point\n> is to discuss UAPI independent of implementation.\n> \n>> ###\n>>\n>> Also, let's agree on this intention. Based on the new ground rule, I\n>> want to point out this example:\n>>\n>> If 'a' gets a program installed with no recurse flag set, ONLY processes\n>> in 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\n>> all stop at cgroup 'b' program.\n> \n> I'm proposing that such situation should not be allowed to happen.\n> In a->b->c->d cgroup scenario if override+recurse prog attached to 'b'\n> then only the same override+recurse can be attached to c, d, a.\n> So at detach time there can be gaps (like only 'b' and 'd' have\n> override+recurse progs), but walking up until root from any point\n> will guarantee that only override+recurse programs are seen.\n> \n\nThat seems very limiting to me. Seems like you are suggesting the entire\ncgroup tree is recursive or non-recursive, but never a mix.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"YzxoVybc\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhnMH0Hk6z9s9Y\n\tfor ;\n\tWed, 30 Aug 2017 11:03:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751669AbdH3BDw (ORCPT );\n\tTue, 29 Aug 2017 21:03:52 -0400","from mail-pf0-f195.google.com ([209.85.192.195]:35643 \"EHLO\n\tmail-pf0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751240AbdH3BDv (ORCPT\n\t); Tue, 29 Aug 2017 21:03:51 -0400","by mail-pf0-f195.google.com with SMTP id g13so3328273pfm.2\n\tfor ; Tue, 29 Aug 2017 18:03:51 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:d89a:ab61:c4f1:b1cb])\n\tby smtp.googlemail.com with ESMTPSA id\n\tf25sm6110519pfe.119.2017.08.29.18.03.49\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 18:03:49 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=DZ+eDZ3aECEfrDrAVIS5pnSEgdhZa/6xGQYCzvlHZ9I=;\n\tb=YzxoVybcUYKBxidEAqbtHq28SlE/doQx08/hYoFfT4Fo1FtCFhZRBULqTjVW1TTBCq\n\tqNqs52Yz5yKh/m70p7cngBfVZrt/CADLOqpALt5T1qQhkaY5IguT+TNUFLZ7CDzi/44g\n\tASClcoLFYbCbePz7ZYvHatYBjVMfFK1pRaEF3l+vmsu1hlfOf7eCf5jok/oPfqy2GMab\n\tTn/6fNX/6Am53HVkUrGvdr1qiIrTDCqp+JuBScB1Myefihy+CsrkgyGlH2wm049jqvU5\n\t8t0HHnXTAdY2MRQYBzqKNNGe3xRkK9QiEqKAVwB88P3zcLz78vZKniaugDa9e6yWoRFo\n\te1CA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=DZ+eDZ3aECEfrDrAVIS5pnSEgdhZa/6xGQYCzvlHZ9I=;\n\tb=kz0w61CNDuEslaXE+wqCaMprrK+2aPT84CIPKt9PAv5VfaJACnFIunhnITi2cfZnNH\n\tpr5bzIfRPc3lh1l7P2KE+TBSEDxxsG1EIhUZ1sG8g1Sygyg+ERxOV/SkE4XTzqHd6gyK\n\tL83jN/DDOn8krn8GEsFnDvtFnDQ7cuaeUfgnycUt2SiC2LYoYT6G6sadIMXWo/aTLIiC\n\t3GQD+Z8jguvppHT+xzCbccF4QCUoSZpJMbko3hXFFkkiA6Ozne5hbUVfUP9sMQSIbsSW\n\tzKn88q7bRoDXlDMJo4POUn51v2f1NAz8Tw96F7t966js3wODsn9JhAZQspJAxSrkz2FF\n\tL0Sw==","X-Gm-Message-State":"AHYfb5j2rbyKmsfVgg50kAaME9DWq6D+Pof3vYi+CT/R1Q6Yts7298TB\n\t4Kfs6B27vpaxkg==","X-Received":"by 10.84.129.162 with SMTP id b31mr2774323plb.303.1504055030628; \n\tTue, 29 Aug 2017 18:03:50 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Alexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>\n\t<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>\n\t<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>","From":"David Ahern ","Message-ID":"","Date":"Tue, 29 Aug 2017 19:03:43 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759824,"web_url":"http://patchwork.ozlabs.org/comment/1759824/","msgid":"<20170830025850.wlp2hp7d4kreodif@ast-mbp>","list_archive_url":null,"date":"2017-08-30T02:58:51","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Tue, Aug 29, 2017 at 07:03:43PM -0600, David Ahern wrote:\n> On 8/28/17 10:11 PM, Alexei Starovoitov wrote:\n> > \n> > Agree on the above, but you're mixing semantics of the new recurse\n> > flag and implementation of it. Ex: we don't have to copy this flag\n> > from prog->attr into cgroup. So this reset or non-reset discussion\n> > only makes sense in the context of your current implementation.\n> > We can implement the logic differently. Like don't copy that flag\n> > at all and at attach time walk parent->parent->parent and see\n> > what programs are attached. All of them should have prog->attr & recurse_bit set\n> > In such implementation detach from 'b' is a nop from reset/non-reset\n> > point of view. When socket creation in 'c' is invoked the program\n> > 'c' is called first then the code keeps walking parents until root\n> > invoking 'a' along the way.\n> \n> So you are suggesting there is no recursive flag per cgroup? How do you\n> know you need to walk cgroups? How do you know when to stop running\n> programs?\n\nyou're talking about implementation, right?\nMy 'proposed' implemenation of walking from cgroup all the way to the root\nis just an example. It's not efficient. More below...\n\n> > I'm not saying it will be an efficient implementation. The point\n> > is to discuss UAPI independent of implementation.\n> > \n> >> ###\n> >>\n> >> Also, let's agree on this intention. Based on the new ground rule, I\n> >> want to point out this example:\n> >>\n> >> If 'a' gets a program installed with no recurse flag set, ONLY processes\n> >> in 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\n> >> all stop at cgroup 'b' program.\n> > \n> > I'm proposing that such situation should not be allowed to happen.\n> > In a->b->c->d cgroup scenario if override+recurse prog attached to 'b'\n> > then only the same override+recurse can be attached to c, d, a.\n> > So at detach time there can be gaps (like only 'b' and 'd' have\n> > override+recurse progs), but walking up until root from any point\n> > will guarantee that only override+recurse programs are seen.\n> > \n> \n> That seems very limiting to me. Seems like you are suggesting the entire\n> cgroup tree is recursive or non-recursive, but never a mix.\n\nEntire cgroup subtree. Yes. It's the simplest uapi I could think of.\nEasy to understand and argue about and I think it's solving your use case.\nIt's also easily extendable. New combination and features won't break\nthe users. It feels you're in rush to get this stuff for this merge\nwindow, therefore I want to agree on something that is simple,\nnon-controversial and extensible.\nIf you're not in rush (I'm not), we can come up with more flexible uapi.\nFor example: another way of thinking about your 'recursive' requirement\nis to think that all 'program to be run' should be present as a link list\nin a given cgroup. So no walking a chain of parents.\nInstead of 'recursive' let's call this new flag 'multiprog'.\nNow in a->b->c->d scenario. We can install 'multiprog' prog in 'b'.\nThe kernel will automatically propage it (like it does right now\nwith css_for_each_descendant_pre() loop) to 'c' and to 'd'.\nNow we allow users to attach another 'multiprog' program to 'c'.\nThe kernel will maintain a link list of programs in every cgroup,\nso there will be a link list of two programs in 'c' and 'd'\nand invocation of the programs will be faster than walking\ncgroup->parent->parent and checking some flags at every step,\nsince there will be less pointer dereferences and no flags to check.\nJust invoke all programs in the current cgroup. Kernel took care\nof ordering at the time of attach/detach.\nI believe Andy proposed something like this back in Jan/Feb.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"M26bLhoE\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhqw26kMJz9sNc\n\tfor ;\n\tWed, 30 Aug 2017 12:58:58 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752033AbdH3C6z (ORCPT );\n\tTue, 29 Aug 2017 22:58:55 -0400","from mail-pf0-f195.google.com ([209.85.192.195]:38025 \"EHLO\n\tmail-pf0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751861AbdH3C6y (ORCPT\n\t); Tue, 29 Aug 2017 22:58:54 -0400","by mail-pf0-f195.google.com with SMTP id r187so3455820pfr.5\n\tfor ; Tue, 29 Aug 2017 19:58:54 -0700 (PDT)","from ast-mbp ([2620:10d:c090:200::5:1651])\n\tby smtp.gmail.com with ESMTPSA id\n\tl9sm7082892pgn.84.2017.08.29.19.58.52\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 19:58:53 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=+7TesKUHBpefZpioWj48Ju3lgIoXVD9JPJ7/yjPFXCU=;\n\tb=M26bLhoEL88p9bEAXwChjGoWKyhy3GDdh6KAosV5KVPAKtjsy+ufiMG+cK7TRUmF+A\n\t2wnoYI26qynTlNS9SNi133B9ETk5IdxgSkqUf5GZgbDEeiew578nsY4A9GI7b4elglfC\n\t4BR9doXjqFIgZOVNG/EnpcjTjEbwSPK63K0H+0u3lH5Uc2m0gUPwi/yLO3M79SMshxtp\n\tgEEKi4T9AK4uGqtfNXH4EAwHL0CUny6njIIMS3cqhxoWEpurnQtt3aAT4veoChdrSYFX\n\t9rkV8tZk43TLOehOkcH+duCwxP6rVXJjo11OHRzuHVu/B07mf1rEqbVCDj2r02uJXo5T\n\tuFVQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=+7TesKUHBpefZpioWj48Ju3lgIoXVD9JPJ7/yjPFXCU=;\n\tb=sEcb+1k7qVREBprmY0E79iaUycXACdNXXSt802WvuSkCtlX0T4dN6a2JK1xYlCOEXN\n\top0K3l0RY8OBLADUTc1MQSlgtvpqhxvA6XijzJTShcM/uQj1gJ0CuNi3itahHP2VMIIa\n\t23xHQ8YFuP2f5fShW00X2r61d+cU+32vvpKBVTI/+W/5KCfxOnvXU9C6pqjYP1/E2WwR\n\tNOcUsLl8EfiiwgF2YMmd1JU9dkSkpVDxVHU+ScrElsibd7oVcshIg0MEdk44KX4GaWGt\n\tnx95p0I5tCucj0i3+1CGcPeuY4kXh28BR0724EyZqzABfWGwQW7h7+gl7ZzeMvlp9364\n\tU8cg==","X-Gm-Message-State":"AHYfb5j2z1OE/5iX/NjoKSHy7U4l1uUIkLZxx+1N1d9OpPykZOEmrGVn\n\tQDgZaAe71TWy2A==","X-Received":"by 10.99.144.68 with SMTP id a65mr76337pge.333.1504061934146;\n\tTue, 29 Aug 2017 19:58:54 -0700 (PDT)","Date":"Tue, 29 Aug 2017 19:58:51 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170830025850.wlp2hp7d4kreodif@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>\n\t<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>\n\t<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759836,"web_url":"http://patchwork.ozlabs.org/comment/1759836/","msgid":"<79498e9c-2b22-d4d7-4b51-8a08e62ba237@gmail.com>","list_archive_url":null,"date":"2017-08-30T03:38:16","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/29/17 8:58 PM, Alexei Starovoitov wrote:\n> On Tue, Aug 29, 2017 at 07:03:43PM -0600, David Ahern wrote:\n>> On 8/28/17 10:11 PM, Alexei Starovoitov wrote:\n>>>\n>>> Agree on the above, but you're mixing semantics of the new recurse\n>>> flag and implementation of it. Ex: we don't have to copy this flag\n>>> from prog->attr into cgroup. So this reset or non-reset discussion\n>>> only makes sense in the context of your current implementation.\n>>> We can implement the logic differently. Like don't copy that flag\n>>> at all and at attach time walk parent->parent->parent and see\n>>> what programs are attached. All of them should have prog->attr & recurse_bit set\n>>> In such implementation detach from 'b' is a nop from reset/non-reset\n>>> point of view. When socket creation in 'c' is invoked the program\n>>> 'c' is called first then the code keeps walking parents until root\n>>> invoking 'a' along the way.\n>>\n>> So you are suggesting there is no recursive flag per cgroup? How do you\n>> know you need to walk cgroups? How do you know when to stop running\n>> programs?\n> \n> you're talking about implementation, right?\n> My 'proposed' implemenation of walking from cgroup all the way to the root\n> is just an example. It's not efficient. More below...\n> \n>>> I'm not saying it will be an efficient implementation. The point\n>>> is to discuss UAPI independent of implementation.\n>>>\n>>>> ###\n>>>>\n>>>> Also, let's agree on this intention. Based on the new ground rule, I\n>>>> want to point out this example:\n>>>>\n>>>> If 'a' gets a program installed with no recurse flag set, ONLY processes\n>>>> in 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\n>>>> all stop at cgroup 'b' program.\n>>>\n>>> I'm proposing that such situation should not be allowed to happen.\n>>> In a->b->c->d cgroup scenario if override+recurse prog attached to 'b'\n>>> then only the same override+recurse can be attached to c, d, a.\n>>> So at detach time there can be gaps (like only 'b' and 'd' have\n>>> override+recurse progs), but walking up until root from any point\n>>> will guarantee that only override+recurse programs are seen.\n>>>\n>>\n>> That seems very limiting to me. Seems like you are suggesting the entire\n>> cgroup tree is recursive or non-recursive, but never a mix.\n> \n> Entire cgroup subtree. Yes. It's the simplest uapi I could think of.\n\nSo 10 email exchanges later you agree on the UAPI I implemented in this\npatch: user opts in to recursive behavior via a new flag at attach time,\nand once a recursive program is installed at some point in the cgroup\ntree it applies to all descendant cgroups.\n\nSo all of these exchanges weren't about the UAPI, but your disagreement\nin my implementation. The only user visible change here is only programs\nmarked recursive are run versus going back to the first cgroup marked\nnon-recursive.\n\n> Easy to understand and argue about and I think it's solving your use case.\n> It's also easily extendable. New combination and features won't break\n> the users. It feels you're in rush to get this stuff for this merge\n> window, therefore I want to agree on something that is simple,\n> non-controversial and extensible.\n\nI am in no-rush, but this does not to fall by the wayside like the net\nnamespace specification.\n\nGiven the pending release of 4.13 net-next will close which gives a 2+\nweek window to work on v3 before the next merge window. Plenty of time\nfor me to work it into the many other things on my plate.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"LjEHW50L\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhrnk2xxSz9sP5\n\tfor ;\n\tWed, 30 Aug 2017 13:38:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752066AbdH3DiX (ORCPT );\n\tTue, 29 Aug 2017 23:38:23 -0400","from mail-pg0-f68.google.com ([74.125.83.68]:37526 \"EHLO\n\tmail-pg0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751778AbdH3DiU (ORCPT\n\t); Tue, 29 Aug 2017 23:38:20 -0400","by mail-pg0-f68.google.com with SMTP id t193so4141017pgc.4\n\tfor ; Tue, 29 Aug 2017 20:38:20 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:d89a:ab61:c4f1:b1cb])\n\tby smtp.googlemail.com with ESMTPSA id\n\tr135sm6438135pfr.109.2017.08.29.20.38.17\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 20:38:18 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=lhNU/2oItiZ/xDr/0ABUC99TXopjNV40WneGoUScuq4=;\n\tb=LjEHW50LOdEwBAT7XkU2qgnw0EH7TAxYH0PS0Fa9/IZK8a+q9n9EEypnxeJGQ+QuKp\n\t3lBh+6NtVn/OTlykeL2HfON+4/U1PKDzw2j6UzYDo9RuWPDjJr2AjTEHtDYkGJ5Ure4L\n\tVcWZODgjUHx7mh0gC2ccqs/QdmOjHKICU2v/w8Msxe1xoyUjU3FIvIo4/C7fm9geS8u8\n\t10IcMKXptDhnxccjDlPDAGE2kgvVarTvs1Pm6Zr6wQnFFk0LQr//rD55hxFcwDXYGeZY\n\tUDJiSWMc2v287wTGhEShBCPxGuMzAah3oDW+m3OkOxbLeipelCgZzqjuHHE2XUubQVxK\n\ttTUw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=lhNU/2oItiZ/xDr/0ABUC99TXopjNV40WneGoUScuq4=;\n\tb=DKX5O3GPa7Th4Po6ecrgmQ9l4wmx1v59igfqGu8cD+a1bPJYUfuKfkW3iBqXMGfpf4\n\tzcf26Sap9HetYHQKqs7CrERdhtf93hQhfAZZoBKFCosXYdc7M58pahtTjtWpdTthk6b9\n\tuwLJlmjFo/rOCEFCUjV8jz37QE9ZeYfNFFghEA3TJX8cJipWv+i/sd9D9VHBwhdyrrSp\n\truSeP12Hxd7LH+jW9HB6pTyGfYyihyoU9W+H6Sxk6tp2B9/AQjMIpRw+fZojitvLD8QI\n\tqQmQnYuMJChp12pttZshg0gcF6EqF4WgQRO/6fxBgTovjz+abeqPvtRQqM7vN9ZDX9Un\n\tatNg==","X-Gm-Message-State":"AHYfb5jJdvf+ZjOAJBzM6bUZ7cTKmrRGgFpIlPEDVCdDRQX2/uXU+336\n\tlXrwJwFSSYp3uYTd","X-Received":"by 10.99.126.91 with SMTP id o27mr157339pgn.299.1504064299681;\n\tTue, 29 Aug 2017 20:38:19 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Alexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>\n\t<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>\n\t<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>\n\t\n\t<20170830025850.wlp2hp7d4kreodif@ast-mbp>","From":"David Ahern ","Message-ID":"<79498e9c-2b22-d4d7-4b51-8a08e62ba237@gmail.com>","Date":"Tue, 29 Aug 2017 21:38:16 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170830025850.wlp2hp7d4kreodif@ast-mbp>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759857,"web_url":"http://patchwork.ozlabs.org/comment/1759857/","msgid":"<20170830041146.q2b52d77x2gwyhco@ast-mbp>","list_archive_url":null,"date":"2017-08-30T04:11:48","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Tue, Aug 29, 2017 at 09:38:16PM -0600, David Ahern wrote:\n> On 8/29/17 8:58 PM, Alexei Starovoitov wrote:\n> > On Tue, Aug 29, 2017 at 07:03:43PM -0600, David Ahern wrote:\n> >> On 8/28/17 10:11 PM, Alexei Starovoitov wrote:\n> >>>\n> >>> Agree on the above, but you're mixing semantics of the new recurse\n> >>> flag and implementation of it. Ex: we don't have to copy this flag\n> >>> from prog->attr into cgroup. So this reset or non-reset discussion\n> >>> only makes sense in the context of your current implementation.\n> >>> We can implement the logic differently. Like don't copy that flag\n> >>> at all and at attach time walk parent->parent->parent and see\n> >>> what programs are attached. All of them should have prog->attr & recurse_bit set\n> >>> In such implementation detach from 'b' is a nop from reset/non-reset\n> >>> point of view. When socket creation in 'c' is invoked the program\n> >>> 'c' is called first then the code keeps walking parents until root\n> >>> invoking 'a' along the way.\n> >>\n> >> So you are suggesting there is no recursive flag per cgroup? How do you\n> >> know you need to walk cgroups? How do you know when to stop running\n> >> programs?\n> > \n> > you're talking about implementation, right?\n> > My 'proposed' implemenation of walking from cgroup all the way to the root\n> > is just an example. It's not efficient. More below...\n> > \n> >>> I'm not saying it will be an efficient implementation. The point\n> >>> is to discuss UAPI independent of implementation.\n> >>>\n> >>>> ###\n> >>>>\n> >>>> Also, let's agree on this intention. Based on the new ground rule, I\n> >>>> want to point out this example:\n> >>>>\n> >>>> If 'a' gets a program installed with no recurse flag set, ONLY processes\n> >>>> in 'a' have the 'a' program run. Processes in groups 'b', 'c' and 'd'\n> >>>> all stop at cgroup 'b' program.\n> >>>\n> >>> I'm proposing that such situation should not be allowed to happen.\n> >>> In a->b->c->d cgroup scenario if override+recurse prog attached to 'b'\n> >>> then only the same override+recurse can be attached to c, d, a.\n> >>> So at detach time there can be gaps (like only 'b' and 'd' have\n> >>> override+recurse progs), but walking up until root from any point\n> >>> will guarantee that only override+recurse programs are seen.\n> >>>\n> >>\n> >> That seems very limiting to me. Seems like you are suggesting the entire\n> >> cgroup tree is recursive or non-recursive, but never a mix.\n> > \n> > Entire cgroup subtree. Yes. It's the simplest uapi I could think of.\n> \n> So 10 email exchanges later you agree on the UAPI I implemented in this\n> patch: user opts in to recursive behavior via a new flag at attach time,\n> and once a recursive program is installed at some point in the cgroup\n> tree it applies to all descendant cgroups.\n> \n> So all of these exchanges weren't about the UAPI, but your disagreement\n> in my implementation. The only user visible change here is only programs\n> marked recursive are run versus going back to the first cgroup marked\n> non-recursive.\n\nyou cannot be serious. Your implemention is not at all what i'm proposing\nabove as a simplest uapi. Should we all go back and re-read from the beginning?\n\n> > Easy to understand and argue about and I think it's solving your use case.\n> > It's also easily extendable. New combination and features won't break\n> > the users. It feels you're in rush to get this stuff for this merge\n> > window, therefore I want to agree on something that is simple,\n> > non-controversial and extensible.\n> \n> I am in no-rush, but this does not to fall by the wayside like the net\n> namespace specification.\n\nIt's more than that! I think you only looking at it from vrf perspective\nwhereas cgroup-bpf became a corner stone feature and enabler for tcp-bpf\nwhich in turn became a stepping stone for bpf_sk_redirect.\nSo no, I'm not going to let something half baked that touches\nthe core idea of cgroup-bpf slide in.\nTejun and Andy also need to take a look, so yes it will take long\ntime for everyone to agree on this core uapi.\n\n> Given the pending release of 4.13 net-next will close which gives a 2+\n> week window to work on v3 before the next merge window. Plenty of time\n> for me to work it into the many other things on my plate.\n\nAs I proposed several emails ago, please repost patches 2 and 3 that\nI already acked and we can continue discussing this patch without\nthe agitation.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"WUMSCKop\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhsXD5Fx6z9sN5\n\tfor ;\n\tWed, 30 Aug 2017 14:11:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751995AbdH3ELx (ORCPT );\n\tWed, 30 Aug 2017 00:11:53 -0400","from mail-pf0-f171.google.com ([209.85.192.171]:36216 \"EHLO\n\tmail-pf0-f171.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751927AbdH3ELw (ORCPT\n\t); Wed, 30 Aug 2017 00:11:52 -0400","by mail-pf0-f171.google.com with SMTP id z87so15997274pfi.3\n\tfor ; Tue, 29 Aug 2017 21:11:52 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:65d0])\n\tby smtp.gmail.com with ESMTPSA id\n\tb29sm8236757pfh.22.2017.08.29.21.11.49\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 29 Aug 2017 21:11:50 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=risbyk+oC2d7c9vGgX2ZaPAmZ6+4fnVR+C7R0E1eMGI=;\n\tb=WUMSCKopSyuHS9ih2aUwSMiNfetqSWlmk6dYrBBPxvLm4ruQhY1iPCnY15MCcMFezv\n\tyEr/vFxqEGi/AOrNH+HU3EtvCItEut2O/lunUA1RR//byzINbLwYysVo0UtWPoOrUkEV\n\twQzt8s8bKVZDA9gtI9OcnUolWKywrUsQd4TsLWooIiz6392cwG/EE5Rs7+jTdS+Zvfgd\n\tHLdB35p1D0h/7JjnrH0mc6/ouQ7YTGm0+vwxqwQxiA1JRerii2tei3jPv4BPTO0e8yIF\n\tnw4USkMa6X3Tu+l6/p8baqwLRLD7EP++RBL7THvQzgUvAHRvAhLgLfYB9Id6oPTZfnvl\n\tkubg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=risbyk+oC2d7c9vGgX2ZaPAmZ6+4fnVR+C7R0E1eMGI=;\n\tb=NwvgRyRr1F1FuB4B3N79MGV52miQig7lyAMkvHcdE5/RjNDH36De8YfjOxkktvjTJC\n\tt/+Q65DiNKOx0avzU/JcDRhqj8ioCDEycEYQJGz4PnWu29QVtPGVeJM7yz+PsW+53XJP\n\tbHBFTClTR2hxzHIX8//WnCg/f2na4qhyhG+CqTntkCDI1Aqf17l9rRDgXTU7SjmKD7t2\n\tjNR9bQQaBkzNVH5KOb6to8UMHsppg22sJtQkOx3nkaPNw9ftLS1Pbqq3J+8lMvDWxYGS\n\tEBKprqVr3wXcQh1SmpuPNMYfks/MzKAB9CdAsLmSf6pMIa52o21VzD2LC5UF96j8SlSC\n\t4KjA==","X-Gm-Message-State":"AHYfb5gfWI+8nRjL9xwxku9GjkRMqm2rMNO4EtI4m1dKu0H4giJ0k24n\n\tzp/4rmRJcGFP7A==","X-Received":"by 10.99.53.71 with SMTP id c68mr253959pga.143.1504066311594;\n\tTue, 29 Aug 2017 21:11:51 -0700 (PDT)","Date":"Tue, 29 Aug 2017 21:11:48 -0700","From":"Alexei Starovoitov ","To":"David Ahern ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\ttj@kernel.org, davem@davemloft.net, luto@amacapital.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170830041146.q2b52d77x2gwyhco@ast-mbp>","References":"<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170828235653.jq62menrcfrh5rco@ast-mbp>\n\t<45102738-365f-d08b-f3cf-9a81683956c4@gmail.com>\n\t<20170829011213.suddt5hkptaxd4rp@ast-mbp>\n\t<32706501-5fc3-7f59-9210-1898e896d384@gmail.com>\n\t<20170829041118.m6bsjvif2bxwtk6g@ast-mbp>\n\t\n\t<20170830025850.wlp2hp7d4kreodif@ast-mbp>\n\t<79498e9c-2b22-d4d7-4b51-8a08e62ba237@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<79498e9c-2b22-d4d7-4b51-8a08e62ba237@gmail.com>","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761050,"web_url":"http://patchwork.ozlabs.org/comment/1761050/","msgid":"<20170831142201.GB1599492@devbig577.frc2.facebook.com>","list_archive_url":null,"date":"2017-08-31T14:22:01","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":352,"url":"http://patchwork.ozlabs.org/api/people/352/","name":"Tejun Heo","email":"tj@kernel.org"},"content":"Hello, David, Alexei.\n\nSorry about late reply.\n\nOn Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n> On 8/25/17 8:49 PM, Alexei Starovoitov wrote:\n> > \n> >> +\tif (prog && curr_recursive && !new_recursive)\n> >> +\t\t/* if a parent has recursive prog attached, only\n> >> +\t\t * allow recursive programs in descendent cgroup\n> >> +\t\t */\n> >> +\t\treturn -EINVAL;\n> >> +\n> >> \told_prog = cgrp->bpf.prog[type];\n> > \n> > ... I'm struggling to completely understand how it interacts\n> > with BPF_F_ALLOW_OVERRIDE.\n> \n> The 2 flags are completely independent. The existing override logic is\n> unchanged. If a program can not be overridden, then the new recursive\n> flag is irrelevant.\n\nI'm not sure all four combo of the two flags makes sense. Can't we\nhave something simpler like the following?\n\n1. None: No further bpf programs allowed in the subtree.\n\n2. Overridable: If a sub-cgroup installs the same bpf program, this\n one yields to that one.\n\n3. Recursive: If a sub-cgroup installs the same bpf program, that\n cgroup program gets run in addition to this one.\n\nNote that we can have combinations of overridables and recursives -\nboth allow further programs in the sub-hierarchy and the only\ndistinction is whether that specific program behaves when that\nhappens.\n\nThanks.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"ESQCH+n4\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjl1v2wKNz9s83\n\tfor ;\n\tFri, 1 Sep 2017 00:22:11 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751622AbdHaOWI (ORCPT );\n\tThu, 31 Aug 2017 10:22:08 -0400","from mail-qt0-f196.google.com ([209.85.216.196]:37129 \"EHLO\n\tmail-qt0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751398AbdHaOWG (ORCPT\n\t); Thu, 31 Aug 2017 10:22:06 -0400","by mail-qt0-f196.google.com with SMTP id g13so601926qta.4\n\tfor ; Thu, 31 Aug 2017 07:22:06 -0700 (PDT)","from localhost (dhcp-ec-8-6b-ed-7a-cf.cpe.echoes.net.\n\t[72.28.26.219]) by smtp.gmail.com with ESMTPSA id\n\tj4sm5680353qtk.3.2017.08.31.07.22.03\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 31 Aug 2017 07:22:04 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=sender:date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=rFFvEO+A1wv34El7RtwKL8OMwWzDjqnJ0RB8P0A3Yyo=;\n\tb=ESQCH+n49oGQcxkBmvTJSmvOS3FQfJ7zzwygH31O6NASlbiK7fOPbdsoM0dxrA4s1Q\n\tVtW5ZcbR/f8Dxl47C6f+ZBjDkoUA1FZs35XAcFtrr7NyK0HawKa8BBN3OBUBWQfNw1qe\n\tgMLgItsod3WhTOose634fkmOhD9R3/b6lq6/JFO9/rmKuG8786DzsEX3E5y8ZsTHHx+4\n\tHuvLElsTv1qPmZyyqjvQ93fnIO4/htn6KMAEz8coh7gU645PjDuyFOLgbOMxagnKVeGr\n\tRSXMcEMGz3I5mRW3lh3uZtQzKDC8lmbMRsE44lefJIXS85ogUoM5vmrUa2YxMjPqI15+\n\toMiQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:sender:date:from:to:cc:subject:message-id\n\t:references:mime-version:content-disposition:in-reply-to:user-agent; \n\tbh=rFFvEO+A1wv34El7RtwKL8OMwWzDjqnJ0RB8P0A3Yyo=;\n\tb=mU2pu9F84Xa7o6KzB+rF47vm2P1Ioqmuz0DAGHSKRM1OLfpgm7vvCMHnwhDCpbM0+N\n\tvMNDbvUmIZZPobFvCV5GStEuG1AxH+7nmq4c69nAL3Y3jO1vVkdfUjSuJZsgo9Y9JOlb\n\tT8MfcOM4Vi/gqcZ24V05VBUozmjfQKBGQhs6/fO/08Qe85rrc3mzuifHizg7I1NUopaB\n\tdaTxfE4oY7/Keoplbai+uNLLj+TRlChuMd8/39EOGWP0iYTDqwGQ00wnQe+yA1bPb8Ty\n\tc3bo0fxFrKiRLGmsbFDk+0L4QP7y0TuBfjgcJg46Fy7T5aVVw1Bk23gHPz9/HjsX0fMj\n\t4zmg==","X-Gm-Message-State":"AHYfb5jwxFKbUxPV2I9alKlLN4zWy8t8dW5F0TnTTAfz47eoRaR2bu8b\n\t6cCj7Ks+Ydki/6ZnSeg=","X-Google-Smtp-Source":"ADKCNb65oJ5ONl34B2hOV4HjafvU9odUJIIc3ODeUTvul2Gm8wSi/QYFM3dzCg6Mbwi+i3eIWgVUFg==","X-Received":"by 10.200.22.205 with SMTP id y13mr8062301qtk.25.1504189325503; \n\tThu, 31 Aug 2017 07:22:05 -0700 (PDT)","Date":"Thu, 31 Aug 2017 07:22:01 -0700","From":"Tejun Heo ","To":"David Ahern ","Cc":"Alexei Starovoitov ,\n\tnetdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\tdavem@davemloft.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170831142201.GB1599492@devbig577.frc2.facebook.com>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761308,"web_url":"http://patchwork.ozlabs.org/comment/1761308/","msgid":"<1db3d38a-dfb5-87de-4aa1-47ecd40f29a2@gmail.com>","list_archive_url":null,"date":"2017-08-31T20:53:31","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":6918,"url":"http://patchwork.ozlabs.org/api/people/6918/","name":"David Ahern","email":"dsahern@gmail.com"},"content":"On 8/31/17 8:22 AM, Tejun Heo wrote:\n> On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n>> On 8/25/17 8:49 PM, Alexei Starovoitov wrote:\n>>>\n>>>> +\tif (prog && curr_recursive && !new_recursive)\n>>>> +\t\t/* if a parent has recursive prog attached, only\n>>>> +\t\t * allow recursive programs in descendent cgroup\n>>>> +\t\t */\n>>>> +\t\treturn -EINVAL;\n>>>> +\n>>>> \told_prog = cgrp->bpf.prog[type];\n>>>\n>>> ... I'm struggling to completely understand how it interacts\n>>> with BPF_F_ALLOW_OVERRIDE.\n>>\n>> The 2 flags are completely independent. The existing override logic is\n>> unchanged. If a program can not be overridden, then the new recursive\n>> flag is irrelevant.\n> \n> I'm not sure all four combo of the two flags makes sense. Can't we\n> have something simpler like the following?\n> \n> 1. None: No further bpf programs allowed in the subtree.\n> \n> 2. Overridable: If a sub-cgroup installs the same bpf program, this\n> one yields to that one.\n> \n> 3. Recursive: If a sub-cgroup installs the same bpf program, that\n> cgroup program gets run in addition to this one.\n> \n> Note that we can have combinations of overridables and recursives -\n> both allow further programs in the sub-hierarchy and the only\n> distinction is whether that specific program behaves when that\n> happens.\n> \n\nI am going to send v3 for patches 2-6 and 8 - the uncontested patches.\n\nAlexei and I will meet in L.A. the week of Sept 11-15 to discuss the\nrecursive implementation (Patch 1 and its testing, patch 7).","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"VdClu0rB\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjvjb6vMyz9t1t\n\tfor ;\n\tFri, 1 Sep 2017 06:53:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751227AbdHaUxf (ORCPT );\n\tThu, 31 Aug 2017 16:53:35 -0400","from mail-pf0-f195.google.com ([209.85.192.195]:38104 \"EHLO\n\tmail-pf0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750908AbdHaUxe (ORCPT\n\t); Thu, 31 Aug 2017 16:53:34 -0400","by mail-pf0-f195.google.com with SMTP id r187so426983pfr.5\n\tfor ; Thu, 31 Aug 2017 13:53:34 -0700 (PDT)","from dsa-mb.local ([2601:282:800:7292:a063:7aab:a8f8:ebdc])\n\tby smtp.googlemail.com with ESMTPSA id\n\tm9sm667379pgt.47.2017.08.31.13.53.32\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 31 Aug 2017 13:53:32 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=p3qV3OhPWU+ZfwTSb5bbBmwUKdiztrzAusPmfmrcT60=;\n\tb=VdClu0rBYjZePKIKOSkhBX6oP2UxhnjV6r6ctX0e0Yd7v1bN5JbpMAW0XHpyQkOjxi\n\t3N6/6WwHiLgTyx7zpGlu93M9cszW9Cqdcpo0JuHjshFmHFsJ81RTERFFrK8Hv56/SAwd\n\t0oiMMUcTDXm9TXxddD/CIIjtaIlgMmedrNtwAjxZvFf3ce8/WPSt7Rqkb9PsoQ0SBANc\n\tvslR1tpDul++3IUboIsE7KpX4i1uYpsi69VrXQnvl5KjcsiaJk58ZdUIz/hzBNMXHRL5\n\t52qd3VZ+l6Gwec9BGa5Wrf1+tt1IOJJiyu5uGY6SWYbTW3lM4DpehELH73kqXzBV8K9W\n\tgJxQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=p3qV3OhPWU+ZfwTSb5bbBmwUKdiztrzAusPmfmrcT60=;\n\tb=TEGlqu9k9WAWsaQKLogH6qBqSdizGIX9Vc31n2nX7HETMV32RAPOF3Re+28nDbhlYW\n\tCuZH9DxqNtY41KV0VjrChKtkgdH+8+m5OvnX7F4/nZFXBMO/7UvXKws/P0hwzPsVJu9B\n\tOjKSeFztBk/ioqPSMioxUrbIZHAieSk7tm1syVeFNNOr1ah7L2n6psoJj34Kc2O5rEZV\n\tA47y5PcTKauk74lEO8Lg1HGBE5juRlko+E5RvJCp/U0osXX1WRsi8IGlNQhML01bnro2\n\tyhgKjaYB3zBQ874pory9p7WUhuDVpXFhFVsaQoWxoAKSAj1vsAd7DRHhXZr5xb4qVXnE\n\tnudw==","X-Gm-Message-State":"AHYfb5icGVcPLrEyTifBm2JA+WmP68/r0I9A6s/qA7SfBInsBU13+5+r\n\tkgYjNgk2cQvUAA==","X-Google-Smtp-Source":"ADKCNb5PF/PYpULjq3nId76HE36mRMZBEgCncvLDcW1WnXgbb4mBV97zWSekJf442Ivgr5bhTF9WMQ==","X-Received":"by 10.99.0.202 with SMTP id 193mr3807425pga.65.1504212814209;\n\tThu, 31 Aug 2017 13:53:34 -0700 (PDT)","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","To":"Tejun Heo ,\n\tAlexei Starovoitov ","Cc":"netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org,\n\tdavem@davemloft.net","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170831142201.GB1599492@devbig577.frc2.facebook.com>","From":"David Ahern ","Message-ID":"<1db3d38a-dfb5-87de-4aa1-47ecd40f29a2@gmail.com>","Date":"Thu, 31 Aug 2017 14:53:31 -0600","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)\n\tGecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170831142201.GB1599492@devbig577.frc2.facebook.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761454,"web_url":"http://patchwork.ozlabs.org/comment/1761454/","msgid":"<20170901032754.ogqmgqaqp3dwfdbw@ast-mbp>","list_archive_url":null,"date":"2017-09-01T03:27:56","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":42586,"url":"http://patchwork.ozlabs.org/api/people/42586/","name":"Alexei Starovoitov","email":"alexei.starovoitov@gmail.com"},"content":"On Thu, Aug 31, 2017 at 07:22:01AM -0700, Tejun Heo wrote:\n> Hello, David, Alexei.\n> \n> Sorry about late reply.\n> \n> On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote:\n> > On 8/25/17 8:49 PM, Alexei Starovoitov wrote:\n> > > \n> > >> +\tif (prog && curr_recursive && !new_recursive)\n> > >> +\t\t/* if a parent has recursive prog attached, only\n> > >> +\t\t * allow recursive programs in descendent cgroup\n> > >> +\t\t */\n> > >> +\t\treturn -EINVAL;\n> > >> +\n> > >> \told_prog = cgrp->bpf.prog[type];\n> > > \n> > > ... I'm struggling to completely understand how it interacts\n> > > with BPF_F_ALLOW_OVERRIDE.\n> > \n> > The 2 flags are completely independent. The existing override logic is\n> > unchanged. If a program can not be overridden, then the new recursive\n> > flag is irrelevant.\n> \n> I'm not sure all four combo of the two flags makes sense. Can't we\n> have something simpler like the following?\n> \n> 1. None: No further bpf programs allowed in the subtree.\n> \n> 2. Overridable: If a sub-cgroup installs the same bpf program, this\n> one yields to that one.\n> \n> 3. Recursive: If a sub-cgroup installs the same bpf program, that\n> cgroup program gets run in addition to this one.\n> \n> Note that we can have combinations of overridables and recursives -\n> both allow further programs in the sub-hierarchy and the only\n> distinction is whether that specific program behaves when that\n> happens.\n\nIf I understand the proposal correctly in case of:\nA (with recurs) -> B (with override) -> C (with recurse) -> D (with override)\nwhen something happens in D, you propose to run D,C,A ?\n\nWith the order of execution from children to parent?\nThat's a bit a different then what I was proposing with 'multi-prog' flag,\nbut the more I think about it the more I like it.\nIn your case detach is sort of transparent to everything around.\nAnd you would also allow to say 'None' to one of the substrees too, right?\nSo something like:\nA (with recurs) -> B (with override) -> C (with recurse) -> D (None) -> E\nwould mean that E cannot attach anything and events in E will\ncall D->C->A, right?\nI will work on a patch for the above and see how it looks.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"fe52kCD/\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xk4Sh12YVz9sNr\n\tfor ;\n\tFri, 1 Sep 2017 13:28:04 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751258AbdIAD2A (ORCPT );\n\tThu, 31 Aug 2017 23:28:00 -0400","from mail-pg0-f67.google.com ([74.125.83.67]:35468 \"EHLO\n\tmail-pg0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750925AbdIAD17 (ORCPT\n\t); Thu, 31 Aug 2017 23:27:59 -0400","by mail-pg0-f67.google.com with SMTP id r133so936344pgr.2\n\tfor ; Thu, 31 Aug 2017 20:27:59 -0700 (PDT)","from ast-mbp ([2620:10d:c090:180::1:f66])\n\tby smtp.gmail.com with ESMTPSA id\n\tz127sm1277188pfb.64.2017.08.31.20.27.57\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 31 Aug 2017 20:27:58 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=BSatm/INOmEjofn1YfjedPMo4bI8gAqWOJ5YPEWfkvg=;\n\tb=fe52kCD/wR/6sZ1ysJtIzG+4F3I5I0J26W9Hiu4s1M0GnciAaQNWuR9F9ElKxEUCtg\n\tVhXH1IiVI13UQ07BdG491Igj7kOfUFMknomoUYEPfOg9ktsvfVX6cB/0voqQHJeWqLLr\n\tg2LIRshbY+UAFL1s3dcQtok5Y/fj9xjRZgaGcvhSPk93FELnzyQs7lVu+Y9wY5aRtwnJ\n\tTgmzBRHbRA/z5YX9DwsQvQiTpXIPMvb9LaX/t73/DNpaGmyLNxgOnQRPYVcBgxeuDyLn\n\tll9MU7HDaS0llaUX9xGdKxKHiLIfDj3l4Nt3QV87NqWjWotv5v2KmBkkGWWKaxZyFVE4\n\tHdBQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=BSatm/INOmEjofn1YfjedPMo4bI8gAqWOJ5YPEWfkvg=;\n\tb=ukV2Xj8anO3ukxyVkpRHDjTJgcylKpn57tVvk07gks+vVydnYKnryU3qAXi7qY7ef5\n\tQ/o417eyD+dW1x1fxcpGng+A/cswXiJ89WCAu5dPLdaklqgcAt27wPddt1ygPquSUr0B\n\t3P61HS0MHYV2R1Vi0qZBCZBHdPM8LB5E6uq4Wv99Oo1tdwRPbPvl0fUqRE4wqgJKOUwL\n\teOws/OY0MrPWZa4r+udMctc0lEPuLbkG1MMSR5xo1AQEuJnvCrOnNA+DsxdGSPtvBhLl\n\tuXvRQseFnedW2Pd3T+dmCYjiqnT7cUrAA2QM/qW1/phdDwuD5lz/IZ9YeM6BmMl3rvwX\n\trCtw==","X-Gm-Message-State":"AHPjjUgUBShvjJ42VdyFRbE/mO1Nj7WuTxJl6Hsl6g1hD3l2+ADhjAFj\n\t7PuA3dTBfZVDPQ==","X-Google-Smtp-Source":"ADKCNb61Sp5xZHZ+zxTiGgb/vxI4anjZ7LcTV4zfjpYhN8mSfreSSIJkaO4dfIzGrXPd/gcJyUoSdA==","X-Received":"by 10.98.88.129 with SMTP id m123mr744128pfb.170.1504236478999; \n\tThu, 31 Aug 2017 20:27:58 -0700 (PDT)","Date":"Thu, 31 Aug 2017 20:27:56 -0700","From":"Alexei Starovoitov ","To":"Tejun Heo ","Cc":"David Ahern , netdev@vger.kernel.org,\n\tdaniel@iogearbox.net, ast@kernel.org, davem@davemloft.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170901032754.ogqmgqaqp3dwfdbw@ast-mbp>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170831142201.GB1599492@devbig577.frc2.facebook.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170831142201.GB1599492@devbig577.frc2.facebook.com>","User-Agent":"NeoMutt/20170421 (1.8.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761719,"web_url":"http://patchwork.ozlabs.org/comment/1761719/","msgid":"<20170901141111.GE1599492@devbig577.frc2.facebook.com>","list_archive_url":null,"date":"2017-09-01T14:11:11","subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","submitter":{"id":352,"url":"http://patchwork.ozlabs.org/api/people/352/","name":"Tejun Heo","email":"tj@kernel.org"},"content":"Hello, Alexei.\n\nOn Thu, Aug 31, 2017 at 08:27:56PM -0700, Alexei Starovoitov wrote:\n> > > The 2 flags are completely independent. The existing override logic is\n> > > unchanged. If a program can not be overridden, then the new recursive\n> > > flag is irrelevant.\n> > \n> > I'm not sure all four combo of the two flags makes sense. Can't we\n> > have something simpler like the following?\n> > \n> > 1. None: No further bpf programs allowed in the subtree.\n> > \n> > 2. Overridable: If a sub-cgroup installs the same bpf program, this\n> > one yields to that one.\n> > \n> > 3. Recursive: If a sub-cgroup installs the same bpf program, that\n> > cgroup program gets run in addition to this one.\n> > \n> > Note that we can have combinations of overridables and recursives -\n> > both allow further programs in the sub-hierarchy and the only\n> > distinction is whether that specific program behaves when that\n> > happens.\n> \n> If I understand the proposal correctly in case of:\n> A (with recurs) -> B (with override) -> C (with recurse) -> D (with override)\n> when something happens in D, you propose to run D,C,A ?\n\nYes, B gets overridden by C, so the effective progarms are A, C and D.\n\n> With the order of execution from children to parent?\n\nHmm... I'm not sure about the execution ordering. How these programs\nchain would be dependent on the type of the program, right? Would we\nbe able to use the same chaining order for all types of programs?\n\n> That's a bit a different then what I was proposing with 'multi-prog' flag,\n> but the more I think about it the more I like it.\n\nGreat.\n\n> In your case detach is sort of transparent to everything around.\n> And you would also allow to say 'None' to one of the substrees too, right?\n> So something like:\n> A (with recurs) -> B (with override) -> C (with recurse) -> D (None) -> E\n> would mean that E cannot attach anything and events in E will\n> call D->C->A, right?\n\nYeap.\n\nThanks.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"p06fVqfZ\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkLkw34tTz9s7c\n\tfor ;\n\tSat, 2 Sep 2017 00:11:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752103AbdIAOLS (ORCPT );\n\tFri, 1 Sep 2017 10:11:18 -0400","from mail-qt0-f172.google.com ([209.85.216.172]:38843 \"EHLO\n\tmail-qt0-f172.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751985AbdIAOLR (ORCPT\n\t); Fri, 1 Sep 2017 10:11:17 -0400","by mail-qt0-f172.google.com with SMTP id w42so1496997qtg.5\n\tfor ; Fri, 01 Sep 2017 07:11:17 -0700 (PDT)","from localhost (dhcp-ec-8-6b-ed-7a-cf.cpe.echoes.net.\n\t[72.28.26.219]) by smtp.gmail.com with ESMTPSA id\n\tr22sm7325455qkl.12.2017.09.01.07.11.13\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 07:11:14 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=sender:date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=PGsyDP61hPyTP4sXMJfvJrEaNnaMbNacksy/yPNTPM4=;\n\tb=p06fVqfZzpksyoi4InRSQW26vhOMgfybmcUCGq7WDOy/GqG0AUPBY5GOzeho0NGKKo\n\t17GnZYCDTfdDWShOxsw12zzSUEmP8+nlmsi3YubZL/1tKPO5xjnQs31Wd34uTy86/uUx\n\t+2/qqUQy/J2AuGHHtrsTPE2MISajVsyT+S0Awz+gAZ95ySKDvG/hQ0FRR2i/NPpqziEc\n\tPnsiiPbJfrde5s0WmkVi5laE7D9QfYZzmGgfsGRp/qcQvIIhol12fJMmbFwE4TsP+w6V\n\t1cT4SiaXFP2dhMe6Rn5iMGJm0VUVoP7hmkQ/fk/Kp+RBrtt5bit3Mq2FARxYXsnlLKCG\n\tZ1oQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:sender:date:from:to:cc:subject:message-id\n\t:references:mime-version:content-disposition:in-reply-to:user-agent; \n\tbh=PGsyDP61hPyTP4sXMJfvJrEaNnaMbNacksy/yPNTPM4=;\n\tb=J3rZiS/F2Bry0wU/dhYKjx9pYdp4x+2IMSWqDh80aTGGme6LrZXUs8Z6jgTXG0P+D6\n\tv/bYL+KsKwGoi0+tsV5g4B4c67cz5b2QD5Unz/3OmwNQcHt8GVSj1Nx5nPrzPFCUATgL\n\teDxew57q/9yE7N5ph6feNvEjLIXFku6Vj6OyIjctj9wavwbA1x9byf6MRtyjkWd85vP/\n\tw4oRkZhTNFpqipn0BlDCm6Vfkb9dRCpkFQqll1yIcrY1pk+rlCShlyqrs+lZEVHzBNR5\n\tHQKBv1ERPuSLBFWVodcKSjkCafidNWxrs7n2nD5eBPFmdb6MWFwBEx76Z2xeuCfzQeV1\n\t0cbw==","X-Gm-Message-State":"AHPjjUiXd6xB2LVDsVWaW0Rpi6qtYeMxenXwFlwNqmkL9Jh4cJrhnAkZ\n\tR+TixtGbFTwrornmI1A=","X-Google-Smtp-Source":"ADKCNb78RtEyMJkgaRVVPbW0x5yUL3zbrOEnMQGSPQyv/xgMu1vGnlBcDw3L+fcoukLxSkso+iF4Hw==","X-Received":"by 10.200.2.147 with SMTP id p19mr3163622qtg.54.1504275076505;\n\tFri, 01 Sep 2017 07:11:16 -0700 (PDT)","Date":"Fri, 1 Sep 2017 07:11:11 -0700","From":"Tejun Heo ","To":"Alexei Starovoitov ","Cc":"David Ahern , netdev@vger.kernel.org,\n\tdaniel@iogearbox.net, ast@kernel.org, davem@davemloft.net","Subject":"Re: [PATCH v2 net-next 1/8] bpf: Add support for recursively running\n\tcgroup sock filters","Message-ID":"<20170901141111.GE1599492@devbig577.frc2.facebook.com>","References":"<1503687941-626-1-git-send-email-dsahern@gmail.com>\n\t<1503687941-626-2-git-send-email-dsahern@gmail.com>\n\t<20170826024957.m5ita6usxihywmdd@ast-mbp>\n\t\n\t<20170831142201.GB1599492@devbig577.frc2.facebook.com>\n\t<20170901032754.ogqmgqaqp3dwfdbw@ast-mbp>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170901032754.ogqmgqaqp3dwfdbw@ast-mbp>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]