linux-kernel - Re: [PATCH v2 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJncD7Sfasoe4-hKZP4c3bPZ892S2Kk5JaMo-aca6eBDwLjLNQ@mail.gmail.com>
Date:   Mon, 19 Jun 2023 16:51:56 +0800
From:   sunliming <kelulanainsley@...il.com>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     mhiramat@...nel.org, rostedt@...dmis.org, shuah@...nel.org,
        linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 1/3] tracing/user_events: Fix incorrect return value
 for writing operation when events are disabled

Beau Belgrave <beaub@...ux.microsoft.com> 于2023年6月17日周六 00:08写道：
>
> On Fri, Jun 09, 2023 at 11:03:00AM +0800, sunliming wrote:
> > The writing operation return the count of writes whether events are
> > enabled or disabled. This is incorrect when events are disabled. Fix
> > this by just return -ENOENT when events are disabled.
> >
>
> When testing this patch locally I found that we would occasionally get
> -ENOENT when events were enabled, but then become disabled, since writes
> do not have any locking around the tracepoint checks for performance
> reasons.
>
> I've asked a few peers of mine their thoughts on this, whether an error
> should result when there are no enabled events. The consensus I've heard
> back is that they would not consider this case an actual error, just as
> writing to /dev/null does not actually return an error.
>
> However, if you feel strongly we need this and have a good use case, it
> seems better to enable this logic behind a flag instead of having it
> default based on my conversations with others.
>
> Thanks,
> -Beau



There is indeed a problem. Once enabled, perform the write operation
immediately.

Now，when the event is disabled, the trace record appears to be lost.
In some situations
where data timing is sensitive, it may cause confusion. In this case,
not returning an
error (as mentioned in your reply, it is not considered this case an
actual error) and
returning 0 ( meaning that the number of data to be written is 0) may
be a good way
to handle it?
Thanks,
-Sunliming

>
> > Signed-off-by: sunliming <sunliming@...inos.cn>
> > ---
> >  kernel/trace/trace_events_user.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> > index 1ac5ba5685ed..92204bbe79da 100644
> > --- a/kernel/trace/trace_events_user.c
> > +++ b/kernel/trace/trace_events_user.c
> > @@ -1957,7 +1957,8 @@ static ssize_t user_events_write_core(struct file *file, struct iov_iter *i)
> >
> >               if (unlikely(faulted))
> >                       return -EFAULT;
> > -     }
> > +     } else
> > +             return -ENOENT;
> >
> >       return ret;
> >  }
> > --
> > 2.25.1