Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1892508imm; Thu, 24 May 2018 02:27:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpHvbDbhAIfEyT6jId0A+PnZazVCPkxOGDhYxRMqSIlf7kZAe5ea+PiLdceUCp5nVcMsWSt X-Received: by 2002:a17:902:547:: with SMTP id 65-v6mr6689559plf.388.1527154032673; Thu, 24 May 2018 02:27:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527154032; cv=none; d=google.com; s=arc-20160816; b=M/mMa9hSmA4hV7inU5muLgvZWEbk3tsZ7cEZExvhW0xbMo6zKsKx5D1WR6jAveHOlI mRthN2qJOgSDbYo07bpktvY+rT7m5uSU//ILB+fTWAYmRXp5cYjKtvVaeES+nygrTsiT kVpxpIebOUQGmNx7lUcirhxUXBgF3IKeBFIT7VetvOCkBV+Z9pvt/ALYuU8QqYup9S2a bqEMFFTX/bRkmLMqB8ILj1tLYE6ShvmGj2lk1VO8JOrvpe5nOobGY/XW6l6UWedat/Kp GkNiijlJjuA0S3Tw4mNybXGLjDdYpID1lwUqmhgaNb26GB0wVNvpNPBEDcq012NeYEbp fk1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=2Ea+J5CIzeC5Gk2cstAbtqPYC4+YZvWQpJeI+f01O8w=; b=bFUosOQCXw3rRF+eOzHFB8DWhliAv7439WHvn8w/nXcT75j3+F13f53e7M/oufzZsI j+FdgvZ1CCix7sffNJoFJK66tqfZgz0+0FxqQrR5/Icw22NSIRNmMbCA4UhzxineV2hE i1lB0QVUV0s+xJvBkPPBNQ/yBuOQTTjOWHgTUZBubSVKD3BvhfaTqjRXJi6YuOxb4TEN 3VEr+MQ81Z0/eB96Uy392Jp/XoUViCO3ldu5mKHhvFymB9pFejehYT7uhpEUJLA+xi+l 1WuUcTv3Pn74FaYCFwN97wnmQuA6TrmvBYeBD5n/QoT4nzWURDcs51JdJsD+8Ow/znBX 8W8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=GKY3QHlR; 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 z190-v6si16286886pgb.108.2018.05.24.02.26.57; Thu, 24 May 2018 02:27:12 -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; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=GKY3QHlR; 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 S965895AbeEXJ0Y (ORCPT + 99 others); Thu, 24 May 2018 05:26:24 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:37393 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965664AbeEXJ0W (ORCPT ); Thu, 24 May 2018 05:26:22 -0400 X-Greylist: delayed 477 seconds by postgrey-1.27 at vger.kernel.org; Thu, 24 May 2018 05:26:22 EDT Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 94FED21C26; Thu, 24 May 2018 05:18:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 24 May 2018 05:18:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=2Ea+J5CIzeC5Gk2cstAbtqPYC4+YZ vWQpJeI+f01O8w=; b=GKY3QHlRxEeATzn5tL5bVu7osaUZo5SPD/5EZk3awqAqs bjBl8I5XNvR+hScOgGwYWDn2Iu2wDeiz7qmf5FMQtw4vxiPTzzB6n361T8mdyjEq gxRpmy/bk9H53KXdL9E8RmYhOwUyVderCICBuzjqb586U1wyI53f9rOxxngaltS8 16C2LGyN/8/GrKsBTlFRcQ7Z/MazBDpTCuZW/6gSZtjpcYgLLrxc5pZ9ZpdjGBX8 qSrzc9aEczJSTcuA2GT6o89d8sfFMASODtxW11EbosZSIj5774UE9jpxmLSgeYtN kiOY/VEMe69f/gpLp1RzrarkPHpzDL5CcXi7DjnzQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost (lfbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.messagingengine.com (Postfix) with ESMTPA id F1F9FE46C2; Thu, 24 May 2018 05:18:23 -0400 (EDT) Date: Thu, 24 May 2018 11:18:07 +0200 From: Greg KH To: Gary R Hook Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 1/2] iommu - Enable debugfs exposure of IOMMU driver internals Message-ID: <20180524091807.GA18148@kroah.com> References: <152631818082.18929.13970142119193316487.stgit@sosxen2.amd.com> <152631842046.18929.1205439632866632871.stgit@sosxen2.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152631842046.18929.1205439632866632871.stgit@sosxen2.amd.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 12:20:20PM -0500, Gary R Hook wrote: > Provide base enablement for using debugfs to expose internal data of an > IOMMU driver. When called, create the /sys/kernel/debug/iommu directory. > > Emit a strong warning at boot time to indicate that this feature is > enabled. > > This function is called from iommu_init, and creates the initial DebugFS > directory. Drivers may then call iommu_debugfs_new_driver_dir() to > instantiate a device-specific directory to expose internal data. > It will return a pointer to the new dentry structure created in > /sys/kernel/debug/iommu, or NULL in the event of a failure. > > Since the IOMMU driver can not be removed from the running system, there > is no need for an "off" function. > > Signed-off-by: Gary R Hook > --- > drivers/iommu/Kconfig | 10 ++++++ > drivers/iommu/Makefile | 1 + > drivers/iommu/iommu-debugfs.c | 72 +++++++++++++++++++++++++++++++++++++++++ > drivers/iommu/iommu.c | 2 + > include/linux/iommu.h | 11 ++++++ > 5 files changed, 96 insertions(+) > create mode 100644 drivers/iommu/iommu-debugfs.c > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index f3a21343e636..2eab6a849a0a 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -60,6 +60,16 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST > > endmenu > > +config IOMMU_DEBUGFS > + bool "Export IOMMU internals in DebugFS" > + depends on DEBUG_FS > + help > + Allows exposure of IOMMU device internals. This option enables > + the use of debugfs by IOMMU drivers as required. Devices can, > + at initialization time, cause the IOMMU code to create a top-level > + debug/iommu directory, and then populate a subdirectory with > + entries as required. You need a big "DO NOT ENABLE THIS OPTION UNLESS YOU REALLY REALLY KNOW WHAT YOU ARE DOING!!!" line here. To match up with your crazy kernel log warning. Otherwise distros will turn this on, I guarantee it. > + > config IOMMU_IOVA > tristate > > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile > index 1fb695854809..74cfbc392862 100644 > --- a/drivers/iommu/Makefile > +++ b/drivers/iommu/Makefile > @@ -2,6 +2,7 @@ > obj-$(CONFIG_IOMMU_API) += iommu.o > obj-$(CONFIG_IOMMU_API) += iommu-traces.o > obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o > +obj-$(CONFIG_IOMMU_DEBUGFS) += iommu-debugfs.o > obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o > obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o > obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o > diff --git a/drivers/iommu/iommu-debugfs.c b/drivers/iommu/iommu-debugfs.c > new file mode 100644 > index 000000000000..bb1bf2d0ac51 > --- /dev/null > +++ b/drivers/iommu/iommu-debugfs.c > @@ -0,0 +1,72 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * IOMMU debugfs core infrastructure > + * > + * Copyright (C) 2018 Advanced Micro Devices, Inc. > + * > + * Author: Gary R Hook > + */ > + > +#include > +#include > +#include > + > +static struct dentry *iommu_debugfs_dir; > + > +/** > + * iommu_debugfs_setup - create the top-level iommu directory in debugfs > + * > + * Provide base enablement for using debugfs to expose internal data of an > + * IOMMU driver. When called, this function creates the > + * /sys/kernel/debug/iommu directory. > + * > + * Emit a strong warning at boot time to indicate that this feature is > + * enabled. > + * > + * This function is called from iommu_init; drivers may then call > + * iommu_debugfs_new_driver_dir() to instantiate a vendor-specific > + * directory to be used to expose internal data. > + */ > +void iommu_debugfs_setup(void) > +{ > + if (!iommu_debugfs_dir) { > + iommu_debugfs_dir = debugfs_create_dir("iommu", NULL); > + if (iommu_debugfs_dir) { No need to care about the return value, just keep going. Nothing you should, or should not, do depending on the return value of a debugfs call. > + pr_warn("\n"); > + pr_warn("*************************************************************\n"); > + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n"); > + pr_warn("** **\n"); > + pr_warn("** IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS KERNEL **\n"); > + pr_warn("** **\n"); > + pr_warn("** This means that this kernel is built to expose internal **\n"); > + pr_warn("** IOMMU data structures, which may compromise security on **\n"); > + pr_warn("** your system. **\n"); > + pr_warn("** **\n"); > + pr_warn("** If you see this message and you are not debugging the **\n"); > + pr_warn("** kernel, report this immediately to your vendor! **\n"); > + pr_warn("** **\n"); > + pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n"); > + pr_warn("*************************************************************\n"); > + } > + } > +} > + > +/** > + * iommu_debugfs_new_driver_dir - create a vendor directory under debugfs/iommu > + * @vendor: name of the vendor-specific subdirectory to create > + * > + * This function is called by an IOMMU driver to create the top-level debugfs > + * directory for that driver. > + * > + * Return: upon success, a pointer to the dentry for the new directory. > + * NULL in case of failure. > + */ > +struct dentry *iommu_debugfs_new_driver_dir(const char *vendor) > +{ > + struct dentry *d_new; > + > + d_new = debugfs_create_dir(vendor, iommu_debugfs_dir); > + > + return d_new; This function can be reduced to 1 line. But really, why do you need it at all? thanks, greg k-h