2023-06-21 06:28:07

by sunliming

[permalink] [raw]
Subject: [PATCH v3 0/3] tracing/user_events: Fix incorrect return value for

Now the writing operation return the count of writes regardless of whether
events are enabled or disabled. Fix this by just return zero when events
are disabled.

v2 -> v3:
- Change the return value from -ENOENT to zero

v1 -> v2:
- Change the return value from -EFAULT to -ENOENT


sunliming (3):
tracing/user_events: Fix incorrect return value for writing operation
when events are disable
selftests/user_events: Enable the event before write_fault test in
ftrace self-test
selftests/user_events: Add test cases when event is diabled

kernel/trace/trace_events_user.c | 3 ++-
tools/testing/selftests/user_events/ftrace_test.c | 7 +++++++
2 files changed, 9 insertions(+), 1 deletion(-)

--
2.25.1



2023-06-21 06:34:13

by sunliming

[permalink] [raw]
Subject: [PATCH v3 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disable

The writing operation return the count of writes regardless of whether events
are enabled or disabled. Switch it to return 0 to indicates that the event
is disabled.

Signed-off-by: sunliming <[email protected]>
---
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..c085ff829a58 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 0;

return ret;
}
--
2.25.1


2023-06-22 20:34:29

by Beau Belgrave

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disable

On Wed, Jun 21, 2023 at 02:08:24PM +0800, sunliming wrote:
> The writing operation return the count of writes regardless of whether events
> are enabled or disabled. Switch it to return 0 to indicates that the event
> is disabled.
>
> Signed-off-by: sunliming <[email protected]>

This looks good to me.

Acked-by: Beau Belgrave <[email protected]>

Thanks!

> ---
> 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..c085ff829a58 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 0;
>
> return ret;
> }
> --
> 2.25.1

2023-06-26 06:38:59

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH v3 1/3] tracing/user_events: Fix incorrect return value for writing operation when events are disable

On Wed, 21 Jun 2023 14:08:24 +0800
sunliming <[email protected]> wrote:

> The writing operation return the count of writes regardless of whether events
> are enabled or disabled. Switch it to return 0 to indicates that the event
> is disabled.
>
> Signed-off-by: sunliming <[email protected]>
> ---
> 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..c085ff829a58 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 0;
>

sunliming,

If you missed the conversation about the pull request with Linus, he
pointed out (correctly) that we were mistaken to tell you to return
zero. It should return an error if the ring buffer is disabled.

But instead of returning -EFAULT, let's follow the behavior of
trace_marker and return -EBADF. This way user space has a better idea
why it failed.

Care to send another update?

Thanks!

-- Steve


> return ret;
> }