Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 20 Jun 2023 11:13:39 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Beau Belgrave <beaub@linux.microsoft.com>
Cc:     sunliming <kelulanainsley@gmail.com>, mhiramat@kernel.org,
        shuah@kernel.org, linux-kernel@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/3] tracing/user_events: Fix incorrect return value
 for writing operation when events are disabled
Message-ID: <20230620111339.44c84a83@gandalf.local.home>
In-Reply-To: <20230619184044.GA88@W11-BEAU-MD.localdomain>
References: <20230609030302.1278716-1-sunliming@kylinos.cn>
        <20230609030302.1278716-2-sunliming@kylinos.cn>
        <20230616160845.GA88@W11-BEAU-MD.localdomain>
        <CAJncD7Sfasoe4-hKZP4c3bPZ892S2Kk5JaMo-aca6eBDwLjLNQ@mail.gmail.com>
        <20230619184044.GA88@W11-BEAU-MD.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

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