linux-kernel - Re: [PATCH] trace: Return ENOTCONN instead of EBADF

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: <20201012104509.6ae404d5@gandalf.local.home>
Date:   Mon, 12 Oct 2020 10:45:09 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Enderborg, Peter" <Peter.Enderborg@...y.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] trace: Return ENOTCONN instead of EBADF

On Mon, 12 Oct 2020 14:26:48 +0000
"Enderborg, Peter" <Peter.Enderborg@...y.com> wrote:

> On 10/12/20 3:53 PM, Steven Rostedt wrote:
> > On Mon, 12 Oct 2020 10:26:42 +0200
> > Peter Enderborg <peter.enderborg@...y.com> 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