Re: [PATCH net-next v7 28/28] net: WireGuard secure network tunnel

[Lukas Wunner <lukas@wunner.de>]

On Sun, Oct 07, 2018 at 07:26:47PM +0200, Jason A. Donenfeld wrote:
> On Sat, Oct 6, 2018 at 9:03 AM Jiri Pirko <jiri@resnulli.us> wrote:
> > >+      wg->incoming_handshakes_worker =
> > >+              wg_packet_alloc_percpu_multicore_worker(
> > >+                              wg_packet_handshake_receive_worker, wg);
> > >+      if (!wg->incoming_handshakes_worker)
> > >+              goto error_2;
> >
> >
> > Please consider renaming the label to "what went wrong". In this case,
> > it would be "err_alloc_worker".

Dan Carpenter, who has probably become the world expert on error paths
in the kernel due to his work on smatch, recommends naming the labels
not "what went wrong" but rather what the error path is going to do,
in this case "err_free_incoming_handshakes_worker" (abbreviate to
"err_free_incoming" or some such):

https://lkml.org/lkml/2016/8/22/374


> > >+      pr_debug("%s: Interface created\n", dev->name);
> > >+      return ret;
> > >+
> > >+error_9:
> > >+      wg_ratelimiter_uninit();
> > >+error_8:
> > >+      wg_packet_queue_free(&wg->decrypt_queue, true);
> > >+error_7:
> > >+      wg_packet_queue_free(&wg->encrypt_queue, true);
> > >+error_6:
> > >+      destroy_workqueue(wg->packet_crypt_wq);
> > >+error_5:
> > >+      destroy_workqueue(wg->handshake_send_wq);
> > >+error_4:
> > >+      destroy_workqueue(wg->handshake_receive_wq);
> > >+error_3:
> > >+      free_percpu(wg->incoming_handshakes_worker);
> > >+error_2:
> > >+      free_percpu(dev->tstats);
> > >+error_1:
> > >+      return ret;
> > >+}
> 
> I'll change away from using error_9,8,7,6,5,4,3,2,1 because of your
> suggestion -- and because it's the norm in the kernel to use real
> names. But, I would be interested in your opinion on the numerical
> errors' reasoning for existing in the first place. The idea was that
> with so many different failure cases that need to cascade in the
> correct order, it's much easier to visually inspect that it's been
> done right by observing up top 1,2,3,4,5,6,7,8,9 and at the bottom
> 9,8,7,6,5,4,3,2,1, rather than having to store in my brain's limited
> stack space what each name pertains to and keep track of the ordering
> and such. In light of that, do you still think that following the
> convention of textual error labels is a good match here? Again, I'm
> changing this for v8, but I am nonetheless curious about what you
> think.

Apart from Dan's clarity argument, what if you need to insert another
step to create the interface, thereby necessitating another step in
the error path?  Are you going to call it 4a, 4b, ...?  Because you
don't want to inflate that future patch by renaming every single
label.

Thanks,

Lukas