From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E9C8C433E0 for ; Sun, 28 Jun 2020 22:28:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E6EFE20720 for ; Sun, 28 Jun 2020 22:28:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726594AbgF1W2s (ORCPT ); Sun, 28 Jun 2020 18:28:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:47104 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbgF1W2r (ORCPT ); Sun, 28 Jun 2020 18:28:47 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A06CD206E9; Sun, 28 Jun 2020 22:28:44 +0000 (UTC) Date: Sun, 28 Jun 2020 18:28:42 -0400 From: Steven Rostedt To: Alexei Starovoitov Cc: Nicolas Boichat , LKML , Ingo Molnar , Andrew Morton , Kees Cook , Jason Gunthorpe , Daniel Vetter , Peter Zijlstra , Vinod Koul , Andy Shevchenko , Alexey Dobriyan , Tiezhu Yang , Thomas Gleixner , "Guilherme G . Piccoli" , Will Deacon , Douglas Anderson , Guenter Roeck , bpf@vger.kernel.org Subject: Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option Message-ID: <20200628182842.2abb0de2@oasis.local.home> In-Reply-To: <20200628220209.3oztcjnzsotlfria@ast-mbp.dhcp.thefacebook.com> References: <20200624084524.259560-1-drinkcat@chromium.org> <20200624120408.12c8fa0d@oasis.local.home> <20200625035913.z4setdowrgt4sqpd@ast-mbp.dhcp.thefacebook.com> <20200626181455.155912d9@oasis.local.home> <20200628172700.5ea422tmw77otadn@ast-mbp.dhcp.thefacebook.com> <20200628144616.52f09152@oasis.local.home> <20200628192107.sa3ppfmxtgxh7sfs@ast-mbp.dhcp.thefacebook.com> <20200628154331.2c69d43e@oasis.local.home> <20200628220209.3oztcjnzsotlfria@ast-mbp.dhcp.thefacebook.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 28 Jun 2020 15:02:09 -0700 Alexei Starovoitov wrote: > > > > Then do a bpf trace event and enable it when a bpf_trace_printk() is > > loaded. It will work the same for your users. > > I'm not sure I follow. How that would preserve the expectation > to see the output in /sys/kernel/debug/tracing/trace ? You create a bpf event just like you create any other event. When a bpf program that uses a bpf_trace_printk() is loaded, you can enable that event from within the kernel. Yes, there's internal interfaces to enabled and disable events just like echoing 1 into tracefs/events/system/event/enable. See trace_set_clr_event(). Then the data of that event will appear in the /sys/kernel/tracing/trace file just like the trace_printk does. The difference is, if something in the kernel decides to use that event, I can easily disable it from user space, where trace_printk() I can't. > > > > Hmm, so you are happier to bully and burn bridges with me to deprecate > > the trace_printk() interface, than to work with me and add an update to > > look into an instance for the print instead of the top level? That's > > not very collaborative. > > I'm seeing it differently. > I'm saying bpf users are complaining about misleading dmesg warning. > You're saying 'screw your users I want to keep that warning'. > Though the warning is lying with a straight face. The only thing happened > is few pages were allocated that will never be freed. The kernel didn't > suddenly become non-production. It didn't become slower. No debug features > were turned on. Come now Alexei. That banner was there from day one trace_printk() was added into the kernel. YOU used this knowing damn well that banner existed. If the bpf users should be upset with someone, it is you for not asking me for how to do this properly from the beginning. This is not a regression. trace_printk() always has shown this, and when I added trace_printk() I stated this is only for debugging a kernel, and not to be kept in mainline. That banner helped enforce that. If I didn't do that, there would be trace_printk()s all over the place, and there's no way to disable one without disabling all the others. This would have made trace_printk() become useless for debugging a kernel, as then you will have to deal with everyone's trace_printks() adding noise to what you want to debug. -- Steve