netdev - Re: [PATCH 2/2] can: m_can: m_can_class_allocate_dev(): remove impossible error return judgment

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20210205081911.4xvabbzdtkvkpplq@hardanger.blackshift.org>
Date:   Fri, 5 Feb 2021 09:19:11 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Xulin Sun <xulin.sun@...driver.com>
Cc:     wg@...ndegger.com, dmurphy@...com, sriram.dash@...sung.com,
        kuba@...nel.org, davem@...emloft.net, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        xulinsun@...il.com
Subject: Re: [PATCH 2/2] can: m_can: m_can_class_allocate_dev(): remove
 impossible error return judgment

On 05.02.2021 15:25:59, Xulin Sun wrote:
> If the previous can_net device has been successfully allocated, its
> private data structure is impossible to be empty, remove this redundant
> error return judgment. Otherwise, memory leaks for alloc_candev() will
> be triggered.

Your analysis is correct, the netdev_priv() will never fail. But how
will this trigger a mem leak on alloc_candev()? I've removed that
statement. I'll add it back, if I've missed something.

> Signed-off-by: Xulin Sun <xulin.sun@...driver.com>

Applied to linux-can-next/testing.

Thanks,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)