From: Dan Carpenter <dan.carpenter@linaro.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: yingsha xu <ysxu@hust.edu.cn>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jiri Benc <jbenc@suse.cz>,
"John W. Linville" <linville@tuxdriver.com>,
hust-os-kernel-patches@googlegroups.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: mac80211: use IS_ERR to check return value
Date: Wed, 19 Apr 2023 14:23:16 +0300 [thread overview]
Message-ID: <85ce5bf1-810d-4a7b-a465-e25aa34f719b@kili.mountain> (raw)
In-Reply-To: <f23c038b2b586a45a8b3c757495d5bb51ee4ac7e.camel@sipsolutions.net>
On Tue, Apr 18, 2023 at 10:36:14AM +0200, Johannes Berg wrote:
> On Sun, 2023-04-16 at 16:30 +0800, yingsha xu wrote:
> > According to the annotation of function debugfs_create_fs, if
> > an error occurs, ERR_PTR(-ERROR) will be returned instead of
> > a null pointer or zero value.
> >
> > Fix it by using IS_ERR().
>
> I don't this this is right, or fixed anything ...
>
> If debugfs indeed returned an ERR_PTR() value, then the later debugfs
> adds will do nothing.
>
> Since it doesn't look like debugfs_create_dir() can actually return NULL
> these days (not sure it ever could), I guess we can even remove the
> check.
>
Correct. They have a patch ready which deletes the check and the
comment. Someone should have replied to this thread to NAK their own
patch so that you didn't bother reviewing it.
> But you could've just read the comment there too, to know what the NULL
> check was about ...
The comment was always wrong. Debugfs could return NULL but then
the other debugfs functions turned into no ops...
regards,
dan carpenter
prev parent reply other threads:[~2023-04-19 11:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-16 8:30 [PATCH] net: mac80211: use IS_ERR to check return value yingsha xu
2023-04-18 8:36 ` Johannes Berg
2023-04-19 11:23 ` Dan Carpenter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85ce5bf1-810d-4a7b-a465-e25aa34f719b@kili.mountain \
--to=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=jbenc@suse.cz \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ysxu@hust.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox