netdev - Re: [PATCH net-next v15 14/15] net: homa: create homa

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <04716a9e-9dad-47e6-9298-5b5cf6efe7cb@lunn.ch>
Date: Tue, 2 Sep 2025 01:03:02 +0200
From: Andrew Lunn <andrew@...n.ch>
To: John Ousterhout <ouster@...stanford.edu>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	edumazet@...gle.com, horms@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next v15 14/15] net: homa: create homa_plumbing.c

On Mon, Sep 01, 2025 at 03:53:35PM -0700, John Ousterhout wrote:
> On Tue, Aug 26, 2025 at 9:17 AM Paolo Abeni <pabeni@...hat.com> wrote:
> 
> > > +     status = proto_register(&homa_prot, 1);
> > > +     if (status != 0) {
> > > +             pr_err("proto_register failed for homa_prot: %d\n", status);
> > > +             goto error;
> > > +     }
> > > +     init_proto = true;
> >
> > The standard way of handling the error paths it to avoid local flags and
> > use different goto labels.
> 
> I initially implemented this with different goto labels, but there
> were so many different labels that the code became unmanageable (very
> difficult to figure out what to change when adding or removing
> initializers). The current approach is *way* cleaner and more obvious,
> so I hope I can keep it. The label approach works best when there is
> only one label that collects all errors.

This _might_ mean you need to split it unto a number of helper
function, with each helper using a goto, and the main function calling
the helper also using goto when a helper returns an error code.

https://www.kernel.org/doc/html/v4.10/process/coding-style.html
says

6) Functions

Functions should be short and sweet, and do just one thing. They
should fit on one or two screenfuls of text (the ISO/ANSI screen size
is 80x24, as we all know), and do one thing and do that well.

The maximum length of a function is inversely proportional to the
complexity and indentation level of that function. So, if you have a
conceptually simple function that is just one long (but simple)
case-statement, where you have to do lots of small things for a lot of
different cases, it’s OK to have a longer function.

However, if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you
think it’s performance-critical, and it will probably do a better job
of it than you would have done).

	Andrew