Linux Kernel Summit discussions
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	ksummit <Ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs
Date: Thu, 04 Oct 2018 18:11:11 +0200	[thread overview]
Message-ID: <s5hh8i17kv4.wl-tiwai@suse.de> (raw)
In-Reply-To: <20181003145351.GB24030@quack2.suse.cz>

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

  reply	other threads:[~2018-10-04 16:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-01 18:04 [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs Steven Rostedt
2018-10-02  1:18 ` Greg KH
2018-10-02  1:26   ` Greg KH
2018-10-02 13:07   ` Steven Rostedt
2018-10-02 14:59     ` Olof Johansson
2018-10-02 16:00       ` Shuah Khan
2018-10-02 16:17         ` Greg Kroah-Hartman
2018-10-02 16:30           ` Greg Kroah-Hartman
2018-10-02 21:37             ` Mauro Carvalho Chehab
2018-10-02 21:57               ` Shuah Khan
2018-10-02 22:22                 ` Greg Kroah-Hartman
2018-10-03 12:59                   ` Jan Kara
2018-10-03 13:40                     ` Greg Kroah-Hartman
2018-10-03 13:44                       ` Jiri Kosina
2018-10-03 14:32                         ` Greg Kroah-Hartman
2018-10-03 14:33                           ` Greg Kroah-Hartman
2018-10-04 11:50                             ` Jiri Kosina
2018-10-03 14:53                       ` Jan Kara
2018-10-04 16:11                         ` Takashi Iwai [this message]
2018-10-03 14:11                     ` Shuah Khan
2018-10-03 10:06               ` Sudeep Holla
2018-10-03 13:13                 ` Mark Brown
2018-10-03 14:52                   ` Sudeep Holla
2018-10-02  8:40 ` Jani Nikula
2018-10-02 13:11   ` Steven Rostedt
2018-10-02 21:32   ` Mauro Carvalho Chehab
2018-10-03  6:23     ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hh8i17kv4.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=Ksummit-discuss@lists.linuxfoundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=mchehab+samsung@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).