All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] tracefs: Only clobber mode/uid/gid on remount if asked
Date: Wed, 7 Sep 2022 14:53:42 -0700	[thread overview]
Message-ID: <YxkS5uzouv2bn6ZB@google.com> (raw)
In-Reply-To: <20220907174813.182df339@gandalf.local.home>

On Wed, Sep 07, 2022 at 05:48:13PM -0400, Steven Rostedt wrote:
> On Wed, 7 Sep 2022 17:46:04 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > >   # Don't change /sys/kernel/tracing/ permissions on automount.
> > >   umount /sys/kernel/debug/tracing/  
> > 
> > BTW, I noticed that the above doesn't do anything. That is,
> > you cannot unmount tracefs from /sys/kernel/debug/tracing.

Actually, it does work, but it's hard to observe. See below.

> I just saw your new email. I guess that's just how you were triggering the
> automount, by unmounting it. Right?

You trimmed the important line:
  stat /sys/kernel/debug/tracing/.

It's hard to observe directly that /sys/kernel/debug/tracing is
unmounted, because traditional examination (stat(2), open(2), etc.)
methods will re-trigger the automount. The automount is *supposed* to
appear as if it is always there.

Try these:

  umount /sys/kernel/debug/tracing/
  grep tracefs /proc/mounts
  stat /sys/kernel/debug/tracing/.
  grep tracefs /proc/mounts

The first and the second grep will give you different results.

> A lot of assumptions about what people may know ;-)

Yes, I suppose. That's also why I figured I'd write a test case, because
test cases tell you exactly what is meant.

Brian

  reply	other threads:[~2022-09-07 21:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-27  0:44 [PATCH 1/2] debugfs: Only clobber mode/uid/gid on remount if asked Brian Norris
2022-08-27  0:44 ` [PATCH 2/2] tracefs: " Brian Norris
2022-09-07 11:44   ` Steven Rostedt
2022-09-07 20:52     ` Brian Norris
2022-09-08  1:25       ` Steven Rostedt
2022-09-07 21:46   ` Steven Rostedt
2022-09-07 21:48     ` Steven Rostedt
2022-09-07 21:53       ` Brian Norris [this message]
2022-09-07 22:45         ` Steven Rostedt
2022-09-01 15:58 ` [PATCH 1/2] debugfs: " Greg Kroah-Hartman
2022-09-01 16:11   ` Steven Rostedt
2022-09-01 22:32   ` Brian Norris
2022-09-02  5:45     ` Greg Kroah-Hartman
2022-09-09  0:16       ` Brian Norris
2022-09-09  0:43         ` Steven Rostedt
2022-09-09  0:57           ` Brian Norris
2022-09-09  1:05             ` Steven Rostedt

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=YxkS5uzouv2bn6ZB@google.com \
    --to=briannorris@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.