Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2732285imm; Sun, 7 Oct 2018 10:27:21 -0700 (PDT) X-Google-Smtp-Source: ACcGV61iHS5qhtlvJDLQwwHJofr91cqSNJqqfLRTbO4l5lR3zjUO0LvrlQn0h6SH1XRelkqrI8LR X-Received: by 2002:a17:902:9a0c:: with SMTP id v12-v6mr20655335plp.159.1538933241050; Sun, 07 Oct 2018 10:27:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538933241; cv=none; d=google.com; s=arc-20160816; b=gMkDour/HM0knvvWv/EEECqPVUTiWArADS/uuuysTAIMAnXP3o9NQ589rI+lUvZj95 AnVqAO3536M/vua8N7vtOLs3ezzsCJmljk5M95tjA2TK/D+BVZ/3KMzmluUcYvtrflkF ovb81t3LEojiV7OlS91ap52yRGSqg8NbJ4PQU9XnjYHF4V+rmXrtgeQzocqCRPyUCGyG O9N72fuCKpHV/8yly3XBEczXKfQ3fqwf+cYcLw8r3PnDpPttBchd9oQKPsrF2GwzJvTA 5HUk+Lqc5C8eu2+N+sTz695YzNfizRkgKXE1bolw3ALoXBNzWgtGhBWd6SbNK1onpH0p dgWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RGMwYR9GWo8iRv3Yb83+qjpfQKQyyBTEO7bBeMaDH6o=; b=L9dzulpqKLEuqV+0Wv2+VpjV0VDXg+x9U02IBfNX9pZQZmrQTaU88V+9CYH6tUUsvx LfAoxZDIDvy7C+s9z7B/qGcRv+V4+e2yR4vsdLdbeC9uQuArMBFTKZ8nwYTWFkAJeFzH ztyrhmqRmn0Bg/VG9S5XGgjjYVbIQP8PkU7WgNjv8X4Jtms6+mtNWo31bZRzfNBahHs5 1Qm3F1urzHJFy54wQktvIlB7TIr4cFrfSS95/2dLrY9vlH7vNs+wT6pdEsLtjwwZ/+QM 6DTUYSWxsIU/6u2GjoKe+COxSDTtSx0BqcOuAi9jc+lJ5/AqujcO+iqan/KwsvhoeaSi h9Tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=mail header.b="lSNc9w/q"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 74-v6si15072894pga.231.2018.10.07.10.27.05; Sun, 07 Oct 2018 10:27:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=mail header.b="lSNc9w/q"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728397AbeJHAe7 (ORCPT + 99 others); Sun, 7 Oct 2018 20:34:59 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:49653 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727383AbeJHAe6 (ORCPT ); Sun, 7 Oct 2018 20:34:58 -0400 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8d2dd9b0; Sun, 7 Oct 2018 17:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=mail; bh=ZvstspmGhTn0kppU5KeTdAScAz8=; b=lSNc9w /q+qLTSPf6dFf+gw/9MYN02KR9mBgWqpOoS/Wx3ICz5cjWR+ECWrneUaQFVH6qAO yLD1/uECbM4y92c/ZwTxOQ32upXUYqwvCIUhJjBsuC/te1Rmz8/E+/JuFk1Wub29 uZlPip+9QBeRagxG6U4dDDLrCxZH+OYcjhW0w2KjRjXUx4BgJzZfrXi4ci48ux4L oCN03/QSwcyF2h0GgzYtJPA7aFCHR+ZpfYTU299AhDZWyz9PRwSPsr+tWTc69t4s 2aaS31bP1p1gQaFM2mAluU75giwdvM8p9r3Zsmoqh+a+Sjux3raam5bSYYt20HvK EQX6Nolm+XllpZmg== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 03738a81 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 7 Oct 2018 17:26:18 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id w81-v6so14070166oiw.9; Sun, 07 Oct 2018 10:26:59 -0700 (PDT) X-Gm-Message-State: ABuFfoi74aI9VyuZkd4yY9vzyJCypiWBAMXfCjZqX0TQUkn1JrInyn0K 1nEFRl40p7xNpsaV3WiONCbZZcVM5tNGAJh2bY8= X-Received: by 2002:aca:b04:: with SMTP id 4-v6mr3287340oil.192.1538933218744; Sun, 07 Oct 2018 10:26:58 -0700 (PDT) MIME-Version: 1.0 References: <20181006025709.4019-1-Jason@zx2c4.com> <20181006025709.4019-29-Jason@zx2c4.com> <20181006065819.GD3061@nanopsycho.orion> In-Reply-To: <20181006065819.GD3061@nanopsycho.orion> From: "Jason A. Donenfeld" Date: Sun, 7 Oct 2018 19:26:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next v7 28/28] net: WireGuard secure network tunnel To: =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= Cc: LKML , Netdev , David Miller , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On Sat, Oct 6, 2018 at 9:03 AM Jiri Pirko 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". > > > >+ > >+ wg->handshake_receive_wq = alloc_workqueue("wg-kex-%s", > >+ WQ_CPU_INTENSIVE | WQ_FREEZABLE, 0, dev->name); > >+ if (!wg->handshake_receive_wq) > >+ goto error_3; > >+ > >+ wg->handshake_send_wq = alloc_workqueue("wg-kex-%s", > >+ WQ_UNBOUND | WQ_FREEZABLE, 0, dev->name); > >+ if (!wg->handshake_send_wq) > >+ goto error_4; > >+ > >+ wg->packet_crypt_wq = alloc_workqueue("wg-crypt-%s", > >+ WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM, 0, dev->name); > >+ if (!wg->packet_crypt_wq) > >+ goto error_5; > >+ > >+ if (wg_packet_queue_init(&wg->encrypt_queue, wg_packet_encrypt_worker, > >+ true, MAX_QUEUED_PACKETS) < 0) > > You need to have "int err" and always in cases like this to do: > err = wg_packet_queue_init() > if (err) > goto err_* > > > >+ goto error_6; > >+ > >+ if (wg_packet_queue_init(&wg->decrypt_queue, wg_packet_decrypt_worker, > >+ true, MAX_QUEUED_PACKETS) < 0) > >+ goto error_7; > >+ > >+ ret = wg_ratelimiter_init(); > >+ if (ret < 0) > >+ goto error_8; > >+ > >+ ret = register_netdevice(dev); > >+ if (ret < 0) > >+ goto error_9; > >+ > >+ list_add(&wg->device_list, &device_list); > >+ > >+ /* We wait until the end to assign priv_destructor, so that > >+ * register_netdevice doesn't call it for us if it fails. > >+ */ > >+ dev->priv_destructor = destruct; > >+ > >+ 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. Jason