[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230616160845.GA88@W11-BEAU-MD.localdomain>
Date: Fri, 16 Jun 2023 09:08:45 -0700
From: Beau Belgrave <beaub@...ux.microsoft.com>
To: sunliming <sunliming@...inos.cn>
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, kelulanainsley@...il.com
Subject: Re: [PATCH v2 1/3] tracing/user_events: Fix incorrect return value
for writing operation when events are disabled
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
> 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
Powered by blists - more mailing lists