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

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] [day] [month] [year] [list]

Message-ID: <20230626021530.26603164@rorschach.local.home>
Date:   Mon, 26 Jun 2023 02:15:30 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     sunliming <sunliming@...inos.cn>
Cc:     mhiramat@...nel.org, beaub@...ux.microsoft.com,
        kelulanainsley@...il.com, linux-trace-kernel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
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 <sunliming@...inos.cn> 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 <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..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;
>  }