On Mon, 19 Jun 2023 11:40:44 -0700 Beau Belgrave beaub@linux.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