From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Levente Kurusa <levex@linux.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] treewide: add missing put_device calls
Date: Sat, 14 Dec 2013 09:24:19 -0800 [thread overview]
Message-ID: <20131214172419.GC22520@kroah.com> (raw)
In-Reply-To: <CAErSpo4dJFsK+Wcfz8PrH=Ras343nLS=XgQFbEr_KCgFVED52Q@mail.gmail.com>
On Fri, Dec 13, 2013 at 01:42:05PM -0700, Bjorn Helgaas wrote:
> [+cc Greg]
>
> On Fri, Dec 13, 2013 at 12:22 PM, Levente Kurusa <levex@linux.com> wrote:
> > Hi,
> >
> > This is just the beginning of patchset-set that aims to fix possible
> > problems caused by not calling put_device() if device_register() fails.
> >
> > The root cause for the need to call put_device() is that the underlying
> > kobject still has a reference count of 1. Thus, device.release() will not
> > be called and the device will just sit there waiting for a put_device().
> > Adding the put_device() also removes the need for the call to kfree() as most
> > release functions already call kfree() on the container of the device.
> >
> > While these have not been experienced, they are potential issues and thus
> > they need to be fixed. Also, they are a few more files that have the same
> > kind of issue, those will be fixed if these are accepted.
>
> Thanks for doing this. This is the sort of mistake that just gets
> copied everywhere, so fixing the examples in the tree will help
> prevent the problem from spreading more.
>
> I don't know if there's really value in having device_register()
> return an error but rely on the caller to do the put_device(). Are
> there cases where the caller still needs the struct device even if
> device_register() fails? E.g., could we do something like this
> instead (I know some callers would also require corresponding changes
> to avoid double puts):
Yeah, that might make more sense, but I was trying to not have the
driver core suddenly free memory if something you pass to it goes wrong.
That's a pretty "odd" thing for an api call to do in the kernel, usually
the caller is always responsible for cleaning up for errors happening.
And there's going to be a ton of changes to get this fixed, as you
really need to do it all in one patch, which makes for a bad "flag-day"
of the api.
thanks,
greg k-h
next prev parent reply other threads:[~2013-12-14 19:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 19:22 [PATCH 0/4] treewide: add missing put_device calls Levente Kurusa
2013-12-13 19:22 ` [PATCH 1/4] net: phy: call put_device on device_register() failure Levente Kurusa
2013-12-13 19:22 ` [PATCH 2/4] eisa: call put_device if device_register fails Levente Kurusa
2013-12-13 19:22 ` [PATCH 3/4] backlight: lcd: " Levente Kurusa
2013-12-13 19:22 ` Levente Kurusa
2013-12-13 19:22 ` [PATCH 4/4] w1: " Levente Kurusa
2013-12-14 15:17 ` Evgeniy Polyakov
2013-12-18 23:47 ` Greg KH
2013-12-23 15:37 ` Джамурахметов Рустафа
2013-12-23 15:38 ` Evgeniy Polyakov
2013-12-13 20:42 ` [PATCH 0/4] treewide: add missing put_device calls Bjorn Helgaas
2013-12-14 17:24 ` Greg Kroah-Hartman [this message]
2013-12-15 7:55 ` Levente Kurusa
2013-12-15 17:03 ` Greg Kroah-Hartman
2013-12-16 17:18 ` Levente Kurusa
2013-12-16 17:58 ` Greg Kroah-Hartman
2013-12-16 18:11 ` Levente Kurusa
2013-12-16 18:18 ` Greg Kroah-Hartman
2013-12-16 18:24 ` Levente Kurusa
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=20131214172419.GC22520@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bhelgaas@google.com \
--cc=levex@linux.com \
--cc=linux-kernel@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.