linux-kernel - Re: [rtla 07/13] rtla: Introduce timerlat

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: <CAAq0SUkchNE50vJEsZDBDQBp88KgzJNJdxaMz=p30h49mxFSHA@mail.gmail.com>
Date: Tue, 25 Nov 2025 15:09:15 -0300
From: Wander Lairson Costa <wander@...hat.com>
To: Crystal Wood <crwood@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, Tomas Glozar <tglozar@...hat.com>, 
	Ivan Pravdin <ipravdin.official@...il.com>, John Kacur <jkacur@...hat.com>, 
	Costa Shulyupin <costa.shul@...hat.com>, Tiezhu Yang <yangtiezhu@...ngson.cn>, 
	"open list:Real-time Linux Analysis (RTLA) tools" <linux-trace-kernel@...r.kernel.org>, 
	open list <linux-kernel@...r.kernel.org>, 
	"open list:BPF [MISC]:Keyword:(?:\\b|_)bpf(?:\\b|_)" <bpf@...r.kernel.org>
Subject: Re: [rtla 07/13] rtla: Introduce timerlat_restart() helper

On Tue, Nov 25, 2025 at 2:36 PM Crystal Wood <crwood@...hat.com> wrote:
>
> On Tue, 2025-11-25 at 11:20 -0300, Wander Lairson Costa wrote:
> > On Mon, Nov 24, 2025 at 9:46 PM Crystal Wood <crwood@...hat.com> wrote:
> > >
> > > On Mon, 2025-11-17 at 15:41 -0300, Wander Lairson Costa wrote:
> >
> > > > +
> > > > +                     if (timerlat_bpf_restart_tracing()) {
> > > > +                             err_msg("Error restarting BPF trace\n");
> > > > +                             return -1;
> > > > +                     }
> > >
> > > [insert rant about not being able to use exceptions in userspace code in
> > > the year 2025]
> > >
> >
> > I actually find exceptions an anti-pattern. Modern languages like Zig,
> > Go and Rust came back to error returning.
>
> Maybe I'm behind the times, but I see exceptions and error returns as
> complementary... not everything should be an exception and I can
> certainly see how they could be overused in an anti-pattern way, but
> they're nice for getting useful information out rather than "something
> failed" without having to add a bunch of debug prints.
>

IIRC, you do get stack trace from the error returns. I think Golang
didn't/don't by
default. Exception as an alias for "panic()" is fine, IMO. What I've
seen in production
is services down due to unhandled exceptions. One of the reasons is
that there is nothing
in the function signature that says if or what of exceptions it raises.

> -Crystal
>