From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: kernel-janitors@vger.kernel.org
Subject: Re: [patch] virtio: console: fix error handling for debugfs_create_dir()
Date: Sun, 21 Jul 2013 15:49:20 +0000 [thread overview]
Message-ID: <20130721154920.GI16598@kroah.com> (raw)
In-Reply-To: <20130719055049.GD9729@elgon.mountain>
On Sun, Jul 21, 2013 at 11:36:25AM +0200, Arnd Bergmann wrote:
> On Saturday 20 July 2013, Dan Carpenter wrote:
> > On Fri, Jul 19, 2013 at 12:28:41PM +0200, Arnd Bergmann wrote:
> > > On Friday 19 July 2013, Dan Carpenter wrote:
> > > > debugfs_create_dir() returns ERR_PTR(-ENODEV) if debugfs is disabled.
> > > > Also my static checker doesn't like it when we print the error code, but
> > > > it's always just NULL.
> > > >
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > This looks wrong. debugfs_create_dir intentionally returns non-NULL so
> > > failing to create the directory does not trigger an error condition if
> > > debugfs is disabled.
> > >
> >
> > Yeah. You're right. But the original code is still wrong and will
> > oops if debugfs is disabled. We should set the pointer to NULL if
> > we get a ERR_PTR().
> >
> > I will send a v2 patch.
>
> I don't see where that oops would happen. In the code I'm looking at,
> all uses of ->debugfs_dir only ever get passed into other debugfs
> functions that are stubbed out to empty inline functions.
>
> It's not the most obvious interface design, but this all seems intentional
> and correct to me.
It was the best interface design I could create, making it very easy for
drivers to use and not really worry at all if debugfs was failing or
not, or if it was even present in the system or not. That was the
design goal I had for it when I wrote it.
thanks,
greg k-h
prev parent reply other threads:[~2013-07-21 15:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-19 5:50 [patch] virtio: console: fix error handling for debugfs_create_dir() Dan Carpenter
2013-07-19 5:50 ` Dan Carpenter
2013-07-19 6:13 ` Amit Shah
2013-07-19 6:25 ` Amit Shah
2013-07-19 10:28 ` Arnd Bergmann
2013-07-19 10:28 ` Arnd Bergmann
2013-07-20 21:50 ` Dan Carpenter
2013-07-20 21:50 ` Dan Carpenter
2013-07-21 9:36 ` Arnd Bergmann
2013-07-22 20:41 ` [patch v2] virtio: console: cleanup an error message Dan Carpenter
2013-07-22 20:41 ` Dan Carpenter
2013-07-23 4:35 ` Greg Kroah-Hartman
2013-07-23 4:35 ` Greg Kroah-Hartman
2013-07-29 7:11 ` Amit Shah
2013-07-29 7:23 ` Amit Shah
2013-07-29 13:12 ` Greg Kroah-Hartman
2013-07-29 13:12 ` Greg Kroah-Hartman
2013-07-29 13:35 ` Dan Carpenter
2013-07-29 13:35 ` Dan Carpenter
2013-07-29 13:44 ` Greg Kroah-Hartman
2013-07-29 13:44 ` Greg Kroah-Hartman
2013-07-30 6:23 ` Rusty Russell
2013-07-30 6:35 ` Rusty Russell
2013-07-21 9:36 ` [patch] virtio: console: fix error handling for debugfs_create_dir() Arnd Bergmann
2013-07-21 15:49 ` Greg Kroah-Hartman
2013-07-21 22:33 ` Dan Carpenter
2013-07-21 22:33 ` Dan Carpenter
2013-07-21 15:49 ` Greg Kroah-Hartman [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=20130721154920.GI16598@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.