Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2056355ybl; Sat, 14 Dec 2019 05:18:05 -0800 (PST) X-Google-Smtp-Source: APXvYqwCqVMWRMLoIo7ALGCRmCMdToKB3Otx+GHn8lRNOQXI2SWmKYLYvS3fuh9Ynb5f8I24PvHa X-Received: by 2002:a05:6830:2001:: with SMTP id e1mr19598877otp.97.1576329485587; Sat, 14 Dec 2019 05:18:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576329485; cv=none; d=google.com; s=arc-20160816; b=aLU7waHDzL+qOZPzLHtRv5HiaITm2H7/wmTy6iL9pZ9zbLSH9q6gCvJ0UBR2djCv7x jWuYR6iIzRcyP58iYOzAG4Xd+VR43R6fyj0xqMzvDml6K9Y0BnaPw/Fjw/t4xexTqFI7 sE10YcGAMS60Ily1C+NuW9y5nMwA0C1YA99NJ3w8ZNrBsnxG27B8mMcpnOtCnITPv8zo P1j1PQqbAkX3nYL9fQc5wq+FU1SbLlB5vmwk8Bl1SHFn9Xdzm+Nt42XRlG29k7VUWIIn e5DhM2nGD8fRufSOkDD6fLfkadY+dZpgDJpuYvWyie8uy88V5Zop/lLTPTv7hpY1TJYy tduw== 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=tXUYo8Z/1wc5z0Jgm8edXNyqrl3xATvrCgL0TB1nk/w=; b=p54r4pozdyqtxUg9jS6sJTNGS4Yisuch9Likh1j4M7J+xDQNFe6JQWOmY37MouJwFF UZI0cY99RD0lFbVZWDQ46nsqC1L/14sQWabOebgKAqoSgE17wQ8bst5EQqIerVZQl/AL CdrB1H6ZppOLIJ3HXLWAUTM8+FxyUyTQRJAG6oyVR1wCs27CA9VA2UtI1GXYh+eiK09b zlfcUGSpPMeZPusZdBV8FzrLq/hlz7YELCb7KNY9rggRswSZnRKtpAQqvlsoFFrEVhMB BXMPTMYw2FnFuEgk0D8YGVOJ/mOPDEoJn9wPeqpyn4FS8QEq+cxUqK+sed1X+TPF7mjU evvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QgmGlJgk; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d11si7506173otc.209.2019.12.14.05.17.42; Sat, 14 Dec 2019 05:18:05 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=QgmGlJgk; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726072AbfLNNO4 (ORCPT + 99 others); Sat, 14 Dec 2019 08:14:56 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:26198 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725809AbfLNNOz (ORCPT ); Sat, 14 Dec 2019 08:14:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576329294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tXUYo8Z/1wc5z0Jgm8edXNyqrl3xATvrCgL0TB1nk/w=; b=QgmGlJgk31M3cdPE5A04rioe+FYAY76MlL83lxm5/g1Oqd/tLnKlHImSEgBOGsm2mCg91D N3kEK6hv+JEXt1SkymJmr6hAPQP0GhPNPxQMTJYkscsbxTTRaWXPjAeqT4/jKwDe9/6ABD kZ6TvMD7Mps9pcBIZq24rL1N0t5gtA0= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-390-vYXazDyDP2S-UDbDhWHZpw-1; Sat, 14 Dec 2019 08:14:50 -0500 X-MC-Unique: vYXazDyDP2S-UDbDhWHZpw-1 Received: by mail-lj1-f200.google.com with SMTP id y15so596303lji.1 for ; Sat, 14 Dec 2019 05:14:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tXUYo8Z/1wc5z0Jgm8edXNyqrl3xATvrCgL0TB1nk/w=; b=FBETb76HiaLN7rdhWBwk+08VSrUjFjUsFkOApXF8ZlA23IiNzmz44hwShuvFGCGgwT gwgiWBNIdX3/F6uyjfWcI2DMTqxnXe/T3YnZgjlxBBrEKw9dCxFB3t6Dfy04CVWblMSg O6u63hVVUhKY1cdlt31qG9SSjnbSCRVOoYooRn+49l0iiamPVuQH5zkZyPi9wngaRVAz FE/UcVMOHHGuYOq36iZ27I7LCQh3zImJ0sw7hJPDrAkPgIVWMSiAcmZK1pLIkV3sD9GP 9jpRQ9w3OHX5ES7lQM2ZBmsiWoZqe0PEbBnaMAR4Vn3DmW1VXENJAagtN/AeG6mvbgsA yZxg== X-Gm-Message-State: APjAAAVjNwGO3pQd3V/AF66wUb+7nFJBpQv/L3mSps1tIuxwMTjzurfq Zm+W0JImYlJkrmtz5Ib7JmmQmO5K76CYhOXOCfCnEDZ4Dkx1qVbf5YDWNKe6rGToYELpuwpc6pR cgvSC2kfTS+jn7n1wIIprEO3YanyPsC7jJModzrXq X-Received: by 2002:a2e:824a:: with SMTP id j10mr13161576ljh.209.1576329289370; Sat, 14 Dec 2019 05:14:49 -0800 (PST) X-Received: by 2002:a2e:824a:: with SMTP id j10mr13161563ljh.209.1576329289135; Sat, 14 Dec 2019 05:14:49 -0800 (PST) MIME-Version: 1.0 References: <20191210152454.86247-1-mcroce@redhat.com> <20191213181051.0f949b17@cakuba.netronome.com> In-Reply-To: <20191213181051.0f949b17@cakuba.netronome.com> From: Matteo Croce Date: Sat, 14 Dec 2019 14:14:13 +0100 Message-ID: Subject: Re: [PATCH net-next] bonding: don't init workqueues on error To: Jakub Kicinski Cc: netdev , Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , LKML 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 On Sat, Dec 14, 2019 at 3:11 AM Jakub Kicinski wrote: > > On Tue, 10 Dec 2019 16:24:54 +0100, Matteo Croce wrote: > > bond_create() initialize six workqueues used later on. > > Work _entries_ not _queues_ no? > Right > > In the unlikely event that the device registration fails, these > > structures are initialized unnecessarily, so move the initialization > > out of the error path. Also, create an error label to remove some > > duplicated code. > > Does the initialization of work entries matter? Is this prep for further > changes? > Not a big issue, I just found useless to initialize those data and free a bit later. Just a cleanup. > > Signed-off-by: Matteo Croce > > --- > > drivers/net/bonding/bond_main.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c > > index fcb7c2f7f001..8756b6a023d7 100644 > > --- a/drivers/net/bonding/bond_main.c > > +++ b/drivers/net/bonding/bond_main.c > > @@ -4889,8 +4889,8 @@ int bond_create(struct net *net, const char *name) > > bond_setup, tx_queues); > > if (!bond_dev) { > > pr_err("%s: eek! can't alloc netdev!\n", name); > > If this is a clean up patch I think this pr_err() could also be removed? > Memory allocation usually fail very loudly so there should be no reason > to print more errors. > Sure, I just didn't want to alter the behaviour too much. > > - rtnl_unlock(); > > - return -ENOMEM; > > + res = -ENOMEM; > > + goto out_unlock; > > } > > > > /* > > @@ -4905,14 +4905,17 @@ int bond_create(struct net *net, const char *name) > > bond_dev->rtnl_link_ops = &bond_link_ops; > > > > res = register_netdevice(bond_dev); > > + if (res < 0) { > > + free_netdev(bond_dev); > > + goto out_unlock; > > + } > > > > netif_carrier_off(bond_dev); > > > > bond_work_init_all(bond); > > > > +out_unlock: > > rtnl_unlock(); > > - if (res < 0) > > - free_netdev(bond_dev); > > return res; > > } > > > > I do appreciate that the change makes the error handling follow a more > usual kernel pattern, but IMHO it'd be even better if the error > handling was completely moved. IOW the success path should end with > return 0; and the error path should contain free_netdev(bond_dev); > > - int res; > + int err; > > [...] > > rtnl_unlock(); > > return 0; > > err_free_netdev: > free_netdev(bond_dev); > err_unlock: > rtnl_unlock(); > return err; > > I'm just not 100% sold on the improvement made by this patch being > worth the code churn, please convince me, respin or get an ack from > one of the maintainers? :) > ACK :) -- Matteo Croce per aspera ad upstream