From: sunliming <kelulanainsley@gmail.com>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: mhiramat@kernel.org, rostedt@goodmis.org, shuah@kernel.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disabled
Date: Mon, 19 Jun 2023 16:51:56 +0800 [thread overview]
Message-ID: <CAJncD7Sfasoe4-hKZP4c3bPZ892S2Kk5JaMo-aca6eBDwLjLNQ@mail.gmail.com> (raw)
In-Reply-To: <20230616160845.GA88@W11-BEAU-MD.localdomain>
Beau Belgrave <beaub@linux.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@kylinos.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
next prev parent reply other threads:[~2023-06-19 8:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 3:02 [PATCH v2 0/3] tracing/user_events: Fix incorrect return value for sunliming
2023-06-09 3:03 ` [PATCH v2 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disabled sunliming
2023-06-16 16:08 ` Beau Belgrave
2023-06-19 8:51 ` sunliming [this message]
2023-06-19 18:40 ` Beau Belgrave
2023-06-20 9:07 ` sunliming
2023-06-20 15:13 ` Steven Rostedt
2023-06-09 3:03 ` [PATCH v2 2/3] selftests/user_events: Enable the event before write_fault test in ftrace self-test sunliming
2023-06-09 3:03 ` [PATCH v2 3/3] selftests/user_events: Add test cases when event is disabled sunliming
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=CAJncD7Sfasoe4-hKZP4c3bPZ892S2Kk5JaMo-aca6eBDwLjLNQ@mail.gmail.com \
--to=kelulanainsley@gmail.com \
--cc=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=shuah@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 NNTP newsgroup(s).