From: Steven Rostedt <rostedt@goodmis.org>
To: Brian Norris <briannorris@chromium.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 07:44:43 -0400 [thread overview]
Message-ID: <20220907074443.3376c766@gandalf.local.home> (raw)
In-Reply-To: <20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid>
On Fri, 26 Aug 2022 17:44:17 -0700
Brian Norris <briannorris@chromium.org> wrote:
> Users may have explicitly configured their tracefs permissions; we
> shouldn't overwrite those just because a second mount appeared.
>
> Only clobber if the options were provided at mount time.
>
> Note: the previous behavior was especially surprising in the presence of
> automounted /sys/kernel/debug/tracing/.
>
> # Don't change /sys/kernel/tracing/ permissions on automount.
> umount /sys/kernel/debug/tracing/
> stat /sys/kernel/debug/tracing/.
>
> # Don't change /sys/kernel/tracing/ permissions.
> mount -t tracefs none /mnt/foo
>
> # Change /sys/kernel/tracing/ mode and uid, but not gid.
> mount -t tracefs -o uid=bar,mode=0750 none /mnt/baz
>
The above text doesn't make sense. Is the comments what you are doing or
what the system is doing? If it is what the system is doing, please show
the output of the stat command and how it is doing something unexpected.
Can you show the example of what is wrong, and what you expected to happen.
The above is just a bunch of commands, but does not display anything that
is incorrect.
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> I'm open to writing an LTP test case for this, if that seems like a good
> idea.
Yes, please add a test :-)
-- Steve
>
> fs/tracefs/inode.c | 31 +++++++++++++++++++++++--------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
>
next prev parent reply other threads:[~2022-09-07 11:44 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 [this message]
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
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=20220907074443.3376c766@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=briannorris@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rafael@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 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.