From: Dan Carpenter <dan.carpenter@linaro.org>
To: Dongliang Mu <dzm91@hust.edu.cn>
Cc: Tomas Henzl <thenzl@redhat.com>, Jing Xu <U202112064@hust.edu.cn>,
Sathya Prakash <sathya.prakash@broadcom.com>,
Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
hust-os-kernel-patches@googlegroups.com,
MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: mpt3sas: mpt3sas_debugfs: return value check of `mpt3sas_debugfs_root`
Date: Mon, 8 May 2023 17:38:55 +0300 [thread overview]
Message-ID: <81d236bb-3913-4eef-bf71-6d17535d6d79@kili.mountain> (raw)
In-Reply-To: <b7154e2c-0438-87d1-9edc-7eb1aad40cd1@hust.edu.cn>
On Mon, May 08, 2023 at 09:40:41PM +0800, Dongliang Mu wrote:
> > > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_debugfs.c b/drivers/scsi/mpt3sas/mpt3sas_debugfs.c
> > > > index a6ab1db81167..c92e08c130b9 100644
> > > > --- a/drivers/scsi/mpt3sas/mpt3sas_debugfs.c
> > > > +++ b/drivers/scsi/mpt3sas/mpt3sas_debugfs.c
> > > > @@ -99,8 +99,6 @@ static const struct file_operations mpt3sas_debugfs_iocdump_fops = {
> > > > void mpt3sas_init_debugfs(void)
> > > > {
> > > > mpt3sas_debugfs_root = debugfs_create_dir("mpt3sas", NULL);
> > > > - if (!mpt3sas_debugfs_root)
> > > > - pr_info("mpt3sas: Cannot create debugfs root\n");
> > > Hi Jing,
> > > most drivers just ignore the return value but here the author wanted to
> > > have the information logged.
> > > Can you instead of removing the message modify the 'if' condition so it
> > > suits the author's intention?
> >
> > This code was always just wrong.
> >
> > The history of this is slightly complicated and boring. These days it's
> > harmless dead code so I guess it's less bad than before.
>
> Hi Dan and Tomas,
>
> Any conclusion about this patch? The student Jing Xu is not sure about how
> to revise this patch.
The correct fix is to delete the code.
Debugfs code has error checking built in and was never supposed to be
checked for errors in normal driver code.
Originally, debugfs returned a mix of error pointers and NULL. In the
kernel, when you have a mix of error pointers and NULL, then the NULL
means that the feature has been disabled deliberately. It's not an
error, we should not print a message.
So a different, correct-ish way to write write debugfs error handling
was to say:
mpt3sas_debugfs_root = debugfs_create_dir("mpt3sas", NULL);
if (IS_ERR(mpt3sas_debugfs_root))
return PTR_ERR(mpt3sas_debugfs_root);
However, in those days, a lot of people didn't understand error pointers
and thought that "if (IS_ERR_OR_NULL(mpt3sas_debugfs_root)) {" was a
super secure way to check for errors. Or they just got it wrong and
checked for NULL instead of error pointers. Any of the checks are
wrong, but if (IS_ERR()) check was at least correct-ish.
I dealt with this a lot because of my work with Smatch. I used to be
happy if I could persuade someone to write at least correct-ish code,
but it was pretty painful to try explain this over and over and very few
people deleted the checks.
Eventually Greg changed the code to never return NULL and mass deleted
the IS_ERR() checks. Not returning NULL makes it simpler to understand.
And it makes it impossible to check in the correct-ish way so it kind of
forces people to just delete the error handling.
regards,
dan carpenter
next prev parent reply other threads:[~2023-05-08 14:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 12:25 Jing Xu
2023-05-02 15:53 ` Tomas Henzl
2023-05-02 17:06 ` Dan Carpenter
2023-05-08 13:40 ` Dongliang Mu
2023-05-08 14:38 ` Dan Carpenter [this message]
2023-05-23 14:48 ` Tomas Henzl
2023-05-23 14:57 ` Dan Carpenter
2023-05-23 17:56 ` Tomas Henzl
2023-05-24 4:16 ` Dan Carpenter
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=81d236bb-3913-4eef-bf71-6d17535d6d79@kili.mountain \
--to=dan.carpenter@linaro.org \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=U202112064@hust.edu.cn \
--cc=dzm91@hust.edu.cn \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sathya.prakash@broadcom.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.com \
--cc=thenzl@redhat.com \
/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
all inboxes | Powered by JetHome®