[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d723d5c1-ed17-41b8-9bc4-274fd8e2b615@stanley.mountain>
Date: Mon, 24 Mar 2025 10:43:31 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Markus Elfring <Markus.Elfring@....de>
Cc: Qasim Ijaz <qasdev00@...il.com>, linux-wireless@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org,
LKML <linux-kernel@...r.kernel.org>,
Angelo Gioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Bo Jiao <bo.jiao@...iatek.com>, Felix Fietkau <nbd@....name>,
James Dutton <james.dutton@...il.com>,
Johannes Berg <johannes@...solutions.net>,
Jonas Gorski <jonas.gorski@...il.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Peter Chiu <chui-hao.chiu@...iatek.com>,
Ryder Lee <ryder.lee@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
Shayne Chen <shayne.chen@...iatek.com>
Subject: Re: wifi: mt76: mt7996: avoid potential null deref in
mt7996_get_et_stats()
On Mon, Mar 24, 2025 at 08:33:39AM +0100, Markus Elfring wrote:
> > Also the "phy" point will never be NULL so the check should be removed.
> How many tools can help to determine such a software aspect with
> inter-procedural analyses?
>
You can just review the code. There is only one caller.
Btw, it's fine to have unnecessary NULL checks so long as they're done
consistently. Generally, we prefer people not add unnecessary code,
but if it makes you feel safer, most maintainers aren't going to nit-pick
you about it. If you are doing the work then you get some say your own
code.
regards,
dan carpenter
Powered by blists - more mailing lists