Received: by 10.192.165.148 with SMTP id m20csp5032673imm; Tue, 24 Apr 2018 12:28:53 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/aEe1Jvm89H6N7KfVfyaquXl48OlOny2bQwgS6nSqIiLbYbCz2Lu03yY82bOJyVpQUlAvh X-Received: by 10.98.207.67 with SMTP id b64mr16856947pfg.248.1524598133661; Tue, 24 Apr 2018 12:28:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524598133; cv=none; d=google.com; s=arc-20160816; b=uPbNJSNh4Fati4WX2MrmwjSxQ45rEcyMUN41rVzTImVpTLUGRO7TIqV1uYDLiqMoKq fyk95oI3j1QThJLV/BA5Ip/KAJNfp7JSplpQpGCAi64pcAreeBQrCDEgHa//FC7JDvOA 12J5wo6+yMAFXHh2rG15/iegxvIWDkg4hha12Jdj88oW3qXmeksUvthI19NyA76tn+Uu xbIFN2AcTFuvqzPXacBqMJlsZUMPwd3Zv420krmo6rP7rogEspviTBMqOxfN0G1yeZq5 SozpAh9s9Ww58nV32HBEPj4vHIkKh50G8hWTNGpYsLf9OCflekwwdJfGi2AyB3eeSWHB v5fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=MD1mfCxa6FayztUI1NofH7D3bxONGU1LCIGccDVwWGI=; b=KR0lWVJRacbwfj6RoHlF0zNvZweoscEbE66UoOvJ2KfXml7kHNyYdq8bo+refW2+sI NaEsSlC+JDSxpUWLH3/MAAOsHPDV8zhYVUlVX2yjbWMlIWkyiP6aSjxpXJ+gJa5xyCnB WZnjw9/K9ed7jQL9IU61xJZMIV1lFdQidfTMtLh4dGytohutlWGgzwxr4FkLcGxi1RlH cQzy39SNKMeRh5fj+XBragfSU82oEoFHMClguqH6IdJIl6DZBZy1tNmE3lxHmw4TJg9v JU/NZ3SwPRdRvts5VD0emMFvwfWNxcFsyAsu36hoZXkGxDLTqpMWEAq2Ab0xQu0Jy+ds vwxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si14097232pll.332.2018.04.24.12.28.39; Tue, 24 Apr 2018 12:28:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751565AbeDXT0P (ORCPT + 99 others); Tue, 24 Apr 2018 15:26:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:34008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbeDXT0K (ORCPT ); Tue, 24 Apr 2018 15:26:10 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 2C40D21774; Tue, 24 Apr 2018 19:26:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C40D21774 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 24 Apr 2018 15:26:07 -0400 From: Steven Rostedt To: Wei Wang Cc: gregkh@linuxfoundation.org, Wei Wang , Ingo Molnar , Andrew Morton , Kees Cook , Peter Zijlstra , Thomas Gleixner , Crt Mori , Alexei Starovoitov , Randy Dunlap , linux-kernel@vger.kernel.org, Joe Perches Subject: Re: [PATCH] do not call trace_printk on non-debug build Message-ID: <20180424152607.71fbee34@gandalf.local.home> In-Reply-To: References: <20180424180812.215900-1-wvw@google.com> <20180424145056.7c29ea18@gandalf.local.home> <20180424151416.397fbbde@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (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 Tue, 24 Apr 2018 19:20:03 +0000 Wei Wang wrote: > checkpatch.pl sounds good. One thing to add is we have many off tree > patches with abuse trace_printk. Also as you mentioned, given this is > really not for use in production and we have been cleaning this our on our > side for years, could we consider to enforce this in kernel? That nasty warning was suppose to be the enforcement. I would expect nobody would ship a kernel where it produced such a message on boot (or loading of a module). If they don't notice, then they are not testing their code. A lot of kernel developers use trace_printk() and I want to make it as easy to use as possible. I don't want to add a config to enable it, because that would be something that could be rather annoying. Let's add it to checkpatch and see if that can draining the swamp of abusers. -- Steve