From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 04 Oct 2018 18:11:11 +0200 Message-ID: From: Takashi Iwai To: Jan Kara In-Reply-To: <20181003145351.GB24030@quack2.suse.cz> References: <20181002090713.71b529fe@gandalf.local.home> <20181002161730.GA7119@kroah.com> <20181002163001.GA11068@kroah.com> <20181002183743.78eac32d@coco.lan> <0e19e6d0-47bd-d57f-8e31-e3521c467fe0@kernel.org> <20181002222238.GA11788@kroah.com> <20181003125916.GB21043@quack2.suse.cz> <20181003134012.GA13071@kroah.com> <20181003145351.GB24030@quack2.suse.cz> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Mauro Carvalho Chehab , Greg Kroah-Hartman , ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 03 Oct 2018 16:53:51 +0200, Jan Kara wrote: > > On Wed 03-10-18 06:40:12, Greg Kroah-Hartman wrote: > > On Wed, Oct 03, 2018 at 02:59:16PM +0200, Jan Kara wrote: > > > On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote: > > > > Luckily debugfs was made "root only by default" a while ago, to help > > > > mitigate this problem. So while it is present on a number of distros, > > > > the "attack surface" is greatly reduced. > > > > > > > > That being said, I bet those distros can drop those config options and > > > > be fine. > > > > > > Not really. We need those configs to be enabled to be able to troubleshoot > > > customer's problems - e.g., asking customer to enable some trace points or > > > show some stats from debugfs is pretty common... > > > > trace points should not be in debugfs. And what stats are in debugfs > > that are not availble in other tools? If you rely on them, shouldn't we > > move them to a "stable" location so that they can always be accessed? > > I personally use e.g. stats under bdi/ directory. And I agree with Jiri > that these things are usually only useful when debugging problems so they > seem to match debugfs purpose rather well. We would not even need debugfs > *mounted* all the time I guess (but then what's the difference between > root-only access currently enforced and not having it mounted, right). But > we do need to have it compiled into the kernel... And I think the problem is that debugfs is mounted as default on our systems. If it's only for debugging purpose, it should be without mounted for the normal usages. Of course, the per-default mount is handier for debugging, and it's easier for developers to gather the information. But this can be done also manually via a debug script like our supportconfig, too. Actually, we'd *love* to have the capability of gathering debug data on the production system, too, so disabling debugfs build is likely no-go. But disabling the mount is a different story, I guess. thanks, Takashi