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

Date:   Tue, 20 Jun 2023 11:13:39 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     sunliming <kelulanainsley@...il.com>, mhiramat@...nel.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

On Mon, 19 Jun 2023 11:40:44 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> > Now，when the event is disabled, the trace record appears to be lost.  
> 
> I'm taking this to mean, if in between the time of the bit check and the
> actual write() /writev() syscall the event becomes disabled, the event
> won't write to the buffer. Yes, that is expected.
> 
> > 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?  
> 
> This is where I get a little lost. What would a user process do with a
> return of 0 bytes? It shouldn't retry, since it just hit that small
> timing window. In reality, it just incurred a temporary excessive
> syscall cost, but no real data loss (the operator/admin turned the event
> off).

Note, this is similar to the race in the kernel with several tracing
activities. If a disable happens and the buffer is now off, but the trace
is still attempted, zero or NULL (depending on the function) is returned.
This just means that tracing is off, and the event should just be dropped.

-- Steve