Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932116AbbFOXBm (ORCPT ); Mon, 15 Jun 2015 19:01:42 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:42280 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751350AbbFOXBd (ORCPT ); Mon, 15 Jun 2015 19:01:33 -0400 Date: Mon, 15 Jun 2015 16:01:30 -0700 (PDT) Message-Id: <20150615.160130.583783771772303463.davem@davemloft.net> To: ast@plumgrid.com Cc: luto@amacapital.net, mingo@kernel.org, rostedt@goodmis.org, wangnan0@huawei.com, lizefan@huawei.com, daniel.wagner@bmw-carit.de, daniel@iogearbox.net, linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next 0/3] bpf: share helpers between tracing and networking From: David Miller In-Reply-To: <1434163154-5218-1-git-send-email-ast@plumgrid.com> References: <1434163154-5218-1-git-send-email-ast@plumgrid.com> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 15 Jun 2015 16:01:33 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1166 Lines: 31 From: Alexei Starovoitov Date: Fri, 12 Jun 2015 19:39:11 -0700 > v1->v2: switched to init_user_ns from current_user_ns as suggested by Andy > > Introduce new helpers to access 'struct task_struct'->pid, tgid, uid, gid, comm > fields in tracing and networking. > > Share bpf_trace_printk() and bpf_get_smp_processor_id() helpers between > tracing and networking. Series applied, thanks. Although I agree with the sentiment that this thing can cause surprising results and can be asking for trouble. If someone wants to filter traffic "by UID" they might make a simple ingress TC ebpf program using these new interfaces and expect it to work. But the UID their program will see will be the UID of whatever randomly happened to be executing when the packet was received and processed. So for these kinds of things such identifying markers are less useful, and perhaps surprising in their results. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/