netdev - Re: [PATCH v2] net/sonic: Fix some resource leaks in error handling paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 11 May 2020 09:54:56 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Finn Thain <fthain@...egraphics.com.au>,
        "David S. Miller" <davem@...emloft.net>,
        Christophe Jaillet <christophe.jaillet@...adoo.fr>,
        netdev@...r.kernel.org
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Thomas Bogendörfer <tsbogend@...ha.franken.de>,
        Chris Zankel <chris@...kel.net>, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v2] net/sonic: Fix some resource leaks in error handling
 paths

> Changed since v1:
>  - Improved commit log slightly.
>  - Changed 'undo_probe1' to 'undo_probe' where appropriate.

I find this response interesting.


> ---

I suggest to replace these triple dashes by a blank line.


>  drivers/net/ethernet/natsemi/macsonic.c | 17 +++++++++++++----
>  drivers/net/ethernet/natsemi/xtsonic.c  |  7 +++++--

I imagine that this change combination will need further clarification
because David Miller provided the information “Applied, thanks.” on 2020-04-27.

net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'
https://lore.kernel.org/patchwork/comment/1426045/
https://lkml.org/lkml/2020/4/27/1014


…
> +++ b/drivers/net/ethernet/natsemi/xtsonic.c
> @@ -229,11 +229,14 @@ int xtsonic_probe(struct platform_device *pdev)
>  	sonic_msg_init(dev);
>
>  	if ((err = register_netdev(dev)))
> -		goto out1;
> +		goto undo_probe1;
>
>  	return 0;
>
> -out1:
> +undo_probe1:
> +	dma_free_coherent(lp->device,
> +			  SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode),
> +			  lp->descriptors, lp->descriptors_laddr);
>  	release_region(dev->base_addr, SONIC_MEM_SIZE);
>  out:
…

Can it be nicer to use the label “free_dma”?

Regards,
Markus