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 [off-list ref] wrote:

quoted

quoted

+      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

quoted

quoted

+      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