From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbbCWRXc (ORCPT ); Mon, 23 Mar 2015 13:23:32 -0400 Received: from mail-qg0-f44.google.com ([209.85.192.44]:35897 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752642AbbCWRW7 (ORCPT ); Mon, 23 Mar 2015 13:22:59 -0400 Message-ID: <55104BF8.8000606@plumgrid.com> Date: Mon, 23 Mar 2015 10:23:04 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ingo Molnar CC: Steven Rostedt , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , "David S. Miller" , Daniel Borkmann , Peter Zijlstra , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 tip 6/9] samples: bpf: simple non-portable kprobe filter example References: <1426894210-27441-1-git-send-email-ast@plumgrid.com> <1426894210-27441-7-git-send-email-ast@plumgrid.com> <20150323072929.GB25184@gmail.com> In-Reply-To: <20150323072929.GB25184@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/23/15 12:29 AM, Ingo Molnar wrote: > >> ** ** >> ** This means that this is a DEBUG kernel and it is ** >> ** unsafe for production use. ** > > But I think printing that it's unsafe for production use is over the > top: it's up to the admin whether it's safe or unsafe, just like > inserting a kprobe can be safe or unsafe. > > Informing that something happened is enough. Well that is Steven's banner and I agree that it's a bit extreme. I think it's done on purpose to scary people away from using trace_printk() for anything other than debug. It applies to both native trace_printk() for kernel debugging and for bpf_trace_printk() for debugging of bpf programs. I don't have a strong opinion about native case, but for bpf I do want this banner to be scary. Otherwise it's too easy to start using bpf_trace_printk() to pass event notifications to user space. bpf_trace_printk and trace_pipe parsing shouldn't be used as a way to communicate between programs and user space. At the end, in actual production use, bpf programs won't be using it and no banner will be seen. Anyway, I don't think I can change this banner in this patch set. If we decide to relax it, it should be done via Steven's tree.