On Wed, 4 Feb 2026 21:17:21 -0500
Steven Rostedt <[email protected]> wrote:

> On Sun,  1 Feb 2026 12:29:15 +0900
> "Masami Hiramatsu (Google)" <[email protected]> wrote:
> 
> > From: Masami Hiramatsu (Google) <[email protected]>
> > 
> > Since there is no reason to reuse the backup instance, make it
> > readonly (but erasable).
> > Note that only backup instances are readonly, because
> > other trace instances will be empty unless it is writable.
> > Only backup instances have copy entries from the original.
> > 
> > With this change, most of the trace control files are removed
> > from the backup instance, including eventfs enable/filter etc.
> > 
> >  # find /sys/kernel/tracing/instances/backup/events/ | wc -l
> >  4093
> >  # find /sys/kernel/tracing/instances/boot_map/events/ | wc -l
> >  9573
> > 
> > Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
> > ---
> >  Changes in v6:
> >    - Remove tracing_on file from readonly instances.
> >    - Remove unused writable_mode from tracing_init_tracefs_percpu().
> >    - Cleanup init_tracer_tracefs() and create_event_toplevel_files().
> >    - Remove TRACE_MODE_WRITE_MASK.
> >    - Add TRACE_ARRAY_FL_RDONLY.
> >  Changes in v5:
> >    - Rebased on the latest for-next (and hide show_event_filters/triggers
> >      if the instance is readonly.
> >  Changes in v4:
> >   - Make trace data erasable. (not reusable)
> >  Changes in v3:
> >   - Resuse the beginning part of event_entries for readonly files.
> >   - Remove readonly file_operations and checking readonly flag in
> >     each write operation.
> >  Changes in v2:
> >   - Use readonly file_operations to prohibit writing instead of
> >     checking flags in write() callbacks.
> >   - Remove writable files from eventfs.
> > ---
> >  kernel/trace/trace.c        |   94 
> > +++++++++++++++++++++++++++++--------------
> >  kernel/trace/trace.h        |    7 +++
> >  kernel/trace/trace_boot.c   |    5 +-
> >  kernel/trace/trace_events.c |   76 ++++++++++++++++++++---------------
> >  4 files changed, 117 insertions(+), 65 deletions(-)
> > 
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 5c3e4a554143..b0efcf1e0809 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -5052,6 +5052,11 @@ static ssize_t
> >  tracing_write_stub(struct file *filp, const char __user *ubuf,
> >                size_t count, loff_t *ppos)
> >  {
> > +   struct trace_array *tr = file_inode(filp)->i_private;
> > +
> > +   if (trace_array_is_readonly(tr))
> > +           return -EPERM;
> > +
> >     return count;
> >  }
> >  
> > @@ -5152,6 +5157,9 @@ tracing_cpumask_write(struct file *filp, const char 
> > __user *ubuf,
> >     cpumask_var_t tracing_cpumask_new;
> >     int err;
> >  
> > +   if (trace_array_is_readonly(tr))
> > +           return -EPERM;
> > +
> 
> Shouldn't these checks be done in the open function? Doing it now is
> too late, as -EPERM on a write is confusing when the open for write
> succeeds.

I've made a small program and straced. Surprisingly, for the super user,
open(2) does not return error on opening a readonly file with O_RDWR.

With normal user, it returns -EACCES
-----
$ strace ./write-test hoge
execve("./write-test", ["./write-test", "hoge"], 0x7ffc30b99928 /* 73 vars */) 
= 0
...
openat(AT_FDCWD, "hoge", O_RDWR)        = -1 EACCES (Permission denied)
exit_group(-1)                          = ?
+++ exited with 255 +++
-----

But for the superuser case:
-----
$ sudo strace ./write-test hoge
execve("./write-test", ["./write-test", "hoge"], 0x7ffcffa80488 /* 32 vars */) 
= 0
...
openat(AT_FDCWD, "hoge", O_RDWR)        = 3
write(3, "test\0", 5)                   = 5
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x2), ...}) = 0
write(1, "write return 5\n", 15write return 5
)        = 15
exit_group(0)                           = ?
+++ exited with 0 +++

So I think we can postpone it until actual action for the superuser case.
(Anyway, I will make it return -EACCES)

Thank you,

> 
> -- Steve
> 
> >     if (count == 0 || count > KMALLOC_MAX_SIZE)
> >             return -EINVAL;
> >  


-- 
Masami Hiramatsu (Google) <[email protected]>

Reply via email to