From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85C81C433E7 for ; Mon, 12 Oct 2020 14:45:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 24CC320838 for ; Mon, 12 Oct 2020 14:45:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389054AbgJLOpL (ORCPT ); Mon, 12 Oct 2020 10:45:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:55328 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388646AbgJLOpL (ORCPT ); Mon, 12 Oct 2020 10:45:11 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BB7ED20776; Mon, 12 Oct 2020 14:45:10 +0000 (UTC) Date: Mon, 12 Oct 2020 10:45:09 -0400 From: Steven Rostedt To: "Enderborg, Peter" Cc: "linux-kernel@vger.kernel.org" , Ingo Molnar Subject: Re: [PATCH] trace: Return ENOTCONN instead of EBADF Message-ID: <20201012104509.6ae404d5@gandalf.local.home> In-Reply-To: <55b99d8d-f75a-e095-63fa-3d5df8b77f1b@sony.com> References: <20201012082642.1394-1-peter.enderborg@sony.com> <20201012095324.78996fd2@gandalf.local.home> <55b99d8d-f75a-e095-63fa-3d5df8b77f1b@sony.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Oct 2020 14:26:48 +0000 "Enderborg, Peter" wrote: > On 10/12/20 3:53 PM, Steven Rostedt wrote: > > On Mon, 12 Oct 2020 10:26:42 +0200 > > Peter Enderborg wrote: > > > >> When there is no clients listening on event the trace return > >> EBADF. The file is not a bad file descriptor and to get the > >> userspace able to do a proper error handling it need a different > >> error code that separate a bad file descriptor from a empty listening. > > I have no problem with this patch, but your description is incorrect. And > > before making this change, I want to make sure that what you think is > > happening is actually happening. > > > > This has nothing to do with "clients listening". This happens when the ring > > buffer is disabled for some reason. The most likely case of this happening > > is if someone sets /sys/kernel/tracing/tracing_on to zero. > > I see that as no one is listening. You start to listen by setting this tracing on > some instance, but that is for trace_pipe. Is it the same flag for raw access and all ways you > can invoke a trace? I don't know what you mean by "setting this tracing on some instance". When you boot up, who is listening? tracing_on is enabled. But there's no listener. > > Would > > "When there is no instances listening on events the trace return What instance are you talking about? What do you think needs to be listening. And no, trace_pipe plays zero role in this. > EBADF, it is when the tracing_on is off globally. The file is not a bad file > descriptor and to get the userspace able to do a proper error handling it need a different > error code that separate a bad file descriptor from a empty listening." > > be a ok? > No. Because I don't understand any of the above! There's no a producer / consumer here. It's a read / write enabled or disabled. If the ring buffer is disabled from write, and you try to write to the ring buffer, you get an error. Basically, it's the same analogy as trying to write to a read-only file. Perhaps the proper error is EPERM. -- Steve