[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241024121325.GJ1202098@kernel.org>
Date: Thu, 24 Oct 2024 13:13:25 +0100
From: Simon Horman <horms@...nel.org>
To: Zhen Lei <thunder.leizhen@...wei.com>
Cc: Rasesh Mody <rmody@...vell.com>,
Sudarsana Kalluru <skalluru@...vell.com>,
GR-Linux-NIC-Dev@...vell.com, Andrew Lunn <andrew+netdev@...n.ch>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] bna: Fix return value check for debugfs create APIs
On Wed, Oct 23, 2024 at 04:09:20PM +0800, Zhen Lei wrote:
> Fix the incorrect return value check for debugfs_create_dir() and
> debugfs_create_file(), which returns ERR_PTR(-ERROR) instead of NULL
> when it fails.
>
> Commit 4ad23d2368cc ("bna: Remove error checking for
> debugfs_create_dir()") allows the program to continue execution if the
> creation of bnad->port_debugfs_root fails, which causes the atomic count
> bna_debugfs_port_count to be unbalanced. The corresponding error check
> need to be added back.
Hi Zhen Lei,
The documentation for debugfs_create_dir states:
* NOTE: it's expected that most callers should _ignore_ the errors returned
* by this function. Other debugfs functions handle the fact that the "dentry"
* passed to them could be an error and they don't crash in that case.
* Drivers should generally work fine even if debugfs fails to init anyway.
Which makes me wonder why we are checking the return value of
debugfs_create_dir() at all. Can't we just take advantage of
it not mattering, to debugfs functions, if the return value
is an error or not?
> Fixes: 4ad23d2368cc ("bna: Remove error checking for debugfs_create_dir()")
> Fixes: 7afc5dbde091 ("bna: Add debugfs interface.")
> Signed-off-by: Zhen Lei <thunder.leizhen@...wei.com>
...
Powered by blists - more mailing lists