Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3691785imm; Tue, 29 May 2018 11:42:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp4cZKGKRCh5zURLK6kOm4MpyJhmUOjlteQ0nOR8xZ113oshnRgzNZrmV8nwZdla/OaCaX4 X-Received: by 2002:a17:902:bb8d:: with SMTP id m13-v6mr15574253pls.46.1527619372015; Tue, 29 May 2018 11:42:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527619371; cv=none; d=google.com; s=arc-20160816; b=i+aW+qm0weFC0BHYA/a32aZUBoVRcMx/IdxIqXBMmzl8sCSsvnSbnke472j1zrSRtK b4LvnnFdJgKxUXzqd/HYq1n9Rip9EIeJFhvHKGr5L74z59S3K6WxH8hovZ32xDoKeb8A U2VCj7xEno4LImf3JRPdn4v2mCUb1CxGka9EM8Nn1KPHh9xWqyLhSSjmh93xJyzvBXBN Kg5xnmz08RdHoyTZ7b1Qo31sLcIxncDVruVm+a8fkOKv7jvU7m4qzvHBnhFoNL4nskuG R0XZEyLbsnp6t3816du25dt3N11G9IfQePUuPLiimJtyNeWCGgHV5oZvQtxpnUG0+Nyv E/WA== 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=6nEbWs0k2ntdBMeTiv8Agi31cuR7PWRHZmD/mcG3h2A=; b=JFnhUj2YoobEdMHI4sPw1eeGsSmiZBgS4ne4fR73sRKv2c5ZmN0dA28chUoEqJrv+c AML7PlNeOccH4WExdGzzivcpnAu+Rgp7XO4XC2nDy2n2rOVm/6sYupGioU89ESihy6M+ vQ061yVFlEcerCG2TC0jQt9baCRduIsgoEp3msjDG/hpgbDW/L2vWjok322wXSL8DjZw Ln+j/fxOZs7mTe/+XowHLdV4Ohwd9bHaUxAgGw9DyFvPfG+CfRgg19eVbEmMzxios4tc fs4qM8ULEsuJxcoO5aYXam+YRsNYpKl8LkrMmbYvbQIFNRLbXBfseZgwaRbLHAGiK2eG 8vyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=BiwdsDzM; 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 d191-v6si7941808pga.192.2018.05.29.11.42.37; Tue, 29 May 2018 11:42:51 -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=BiwdsDzM; 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 S966022AbeE2SlX (ORCPT + 99 others); Tue, 29 May 2018 14:41:23 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:34487 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932798AbeE2SlV (ORCPT ); Tue, 29 May 2018 14:41:21 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4007F213FC; Tue, 29 May 2018 14:41:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 29 May 2018 14:41:21 -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=6nEbWs0k2ntdBMeTiv8Agi31cuR7P WRHZmD/mcG3h2A=; b=BiwdsDzMj6OZRWwSo5N2hw1PBelCfMdXiBjx2XuunDY0D N985kCatEBqCjBvXCFkjpHfm6ETMmpywOdvtNn22/p7+qGrSFv1tlobW0nKLoVTx mJrEXqW4X8FHQWomi/IBuLvvRlHCVmR9HIcd4FEv0Q5nkEztl+Zinb4/qNKAaTiA nRolqDwwTLVIWCgP5BC3GMgXVGf8PUMpSEZzthjwqv4s8INPbs67+xpAt+C3xDtl heyw3HXp6AnssRaXXQifhc1JUWelYp5xKSVo6q/9N2j+ewe5vBKG2sbk6ILIFRed qz9np4eEikJzmW3n+T4qajGhFKGELEHGer8rqWg6A== 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 BEC6910265; Tue, 29 May 2018 14:41:20 -0400 (EDT) Date: Tue, 29 May 2018 20:41:01 +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 v8 1/2] iommu - Enable debugfs exposure of IOMMU driver internals Message-ID: <20180529184101.GB10618@kroah.com> References: <152761784341.2654.8609366076331539902.stgit@sosgrh1.amd.com> <152761819480.2654.5371070582955429468.stgit@sosgrh1.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152761819480.2654.5371070582955429468.stgit@sosgrh1.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 Tue, May 29, 2018 at 01:23:14PM -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 c76157e57f6b..f9af25ac409f 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 didn't put a big enough warning here, like I asked last time :( > + > 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) { Again, no, never test a return value from a debugfs call. You do not care, you should do the same exact thing if it is enabled or disabled or somehow failing. Just keep moving on. > + 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; > +} > +EXPORT_SYMBOL_GPL(iommu_debugfs_new_driver_dir); Why are you wrapping a debugfs call? Why not just export iommu_debugfs_dir instead? thanks, greg k-h