Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp725009ybk; Sat, 9 May 2020 16:48:48 -0700 (PDT) X-Google-Smtp-Source: APiQypLsTT0N99SYz5GVUZ3YAiBirEwBPDhzmvKmFbNJqfcs0mh70yDZnMN+vHcrRlzsmEpsFRKC X-Received: by 2002:a17:906:f1d2:: with SMTP id gx18mr8264641ejb.24.1589068128082; Sat, 09 May 2020 16:48:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589068128; cv=none; d=google.com; s=arc-20160816; b=lhxyyLzZpIOSPThvWXwvVoJ9pvsecwgmrQstl6hfjrQMy+3DbieXHQhgGRvNaGHnUh 567cFpuRiUf7WJeGi9flXhVx0EjTwXoKGZWn/OCahuuY1/ZB+eVT6LcptwCp3nrAwvfO YrVos9CBnvf9sE+zQkenU/PnbBxSdk1nIjF0jLZlo1qO53/qDtYdjio+Lv12jXZz9YlI 8yQ7mvPOenKK3UyIMMKLvTp6+9xdJQIq8K4ReH5gdsc2pztVVc5NUUAGEHnPlXEFNfcE qaoVUa/wHBn0LJLWypbevnNcv7WUvDSA8uDfEjN0qqyQBf8IQYylWWqoa+qDEK3UEfTr YnfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=zU1PoCZqIZ/WySQcGuiX2SScQMDYH2McodpIsqaLCwc=; b=aKoxklmX35eQ1zO7BYo1XXc/Y3z4iDQlAwKDTvfCJJvN6B0UbxO2AvUd/v1mkTJiTg PIhJLHw4QWhMA9Bz0ZT3bNXZlqcgrB/a/p5K5rIgtdHG3qDtud8dE/zuf3xeU8pX0r0Y KWDSI9cM91fm44yMuwM9CsxhOJx9mD3YyV42/Kf9wT7Su1PKOOcybEVtYDfSt1rbNImg PmZHSP1qcgv402UBAEye5aStANPhJt8m3Fwn7lXU4vET96tdzxF6IWR0wVhwja1IeGYw VDyuKFflLE4AhsDnEAu7govVOB+Hp/3FQDdQa4NXDZkej8dSm6RK9idUcwPIeJTEwtgj 4IKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw6si3349978edb.552.2020.05.09.16.48.25; Sat, 09 May 2020 16:48:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728464AbgEIXpN (ORCPT + 99 others); Sat, 9 May 2020 19:45:13 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:36424 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726209AbgEIXpM (ORCPT ); Sat, 9 May 2020 19:45:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 38C3F2996C; Sat, 9 May 2020 19:45:09 -0400 (EDT) Date: Sun, 10 May 2020 09:45:04 +1000 (AEST) From: Finn Thain To: Markus Elfring cc: Christophe Jaillet , netdev@vger.kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Jakub Kicinski Subject: Re: [PATCH] net/sonic: Fix some resource leaks in error handling paths In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 9 May 2020, Markus Elfring wrote: > > While at it, rename a label in order to be slightly more informative and > > split some too long lines. > > Would you like to add the tag 'Fixes' to the change description? > Sorry but I don't follow your reasoning here. Are you saying that this needs to be pushed out to -stable branches? If so, stable-kernel-rules.rst would seem to disagree as the bug is theoretical and isn't bothering people. Is there a way to add a Fixes tag that would not invoke the -stable process? And was that what you had in mind? > > > +++ b/drivers/net/ethernet/natsemi/macsonic.c > > @@ -506,10 +506,14 @@ static int mac_sonic_platform_probe(struct platform_device *pdev) > > > > err = register_netdev(dev); > > if (err) > > - goto out; > > + goto undo_probe1; > > > > return 0; > > > > +undo_probe1: > > + dma_free_coherent(lp->device, > > + SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode), > > + lp->descriptors, lp->descriptors_laddr); > > out: > How do you think about the possibility to use the label 'free_dma'? I think 'undo_probe1' is both descriptive and consistent with commit 10e3cc180e64 ("net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'"). Your suggestion, 'free_dma' is also good. But coming up with good alternatives is easy. If every good alternative would be considered there would be no obvious way to get a patch merged.