From: Greg KH <greg@kroah.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers-core: nullify private pointer on device-release
Date: Mon, 5 Oct 2009 09:30:23 -0700 [thread overview]
Message-ID: <20091005163023.GA31280@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0910051811210.4337@axis700.grange>
On Mon, Oct 05, 2009 at 06:14:37PM +0200, Guennadi Liakhovetski wrote:
> On Mon, 5 Oct 2009, Greg KH wrote:
>
> > On Mon, Oct 05, 2009 at 10:11:50AM +0200, Guennadi Liakhovetski wrote:
> > > On Thu, 1 Oct 2009, Greg KH wrote:
> > >
> > > > On Thu, Oct 01, 2009 at 03:45:56PM +0200, Guennadi Liakhovetski wrote:
> > > > > On Thu, 1 Oct 2009, Greg KH wrote:
> > > > >
> > > > > > On Thu, Oct 01, 2009 at 10:02:08AM +0200, Guennadi Liakhovetski wrote:
> > > > > > > Device structures can be reused over multiple device_add / device_release
> > > > > > > cycles.
> > > > > >
> > > > > > They shouldn't be as they should be dynamic, not static.
> > > > >
> > > > > Should they? I'm pretty sure this is not the first time this comes up -
> > > > > there are several drivers and / or subsystems, that re-use driver objects.
> > > >
> > > > Then those drivers and subsystems should be fixed, as that is incorrect.
> > > >
> > > > > But finding in mail archives wouldn't be very easy. And it worked until
> > > > > now - why should we break it?
> > > >
> > > > I would argue that this code was always broken.
> > > > When did this problem show up for you?
> > >
> > > Since commit b4028437876866aba4747a655ede00f892089e14
> >
> > Again, which driver/devices are having this problem?
>
> Quoting my previous reply in this thread:
>
> > > What device is having this problem?
> >
> > My problem case is the soc-camera framework. There device struct is
> > embedded into the video client object, which are kept as long as the
> > driver is loaded.
>
> </quote>
Ok, then that code needs to be fixed :)
> > The patch
> > referenced above had been in linux-next for almost 6 months with no
> > reported problems, so this is news to me :)
>
> Hm, really 6 months in linux-next? That surprises me too, that I didn't
> notice it until now. But in any case, the aforementioned commit introduced
> a regression. If you disagree, that it has to be fixed centrally as per
> proposed patch, no problem, I'm pushing a patch tonight, that will fix
> this for soc-camera. No idea about other drivers.
Great, glad to see this being fixed where it should be. As no one else
has reported a problem, I'm guessing that this is the only incorrect
code.
thanks,
greg k-h
prev parent reply other threads:[~2009-10-05 16:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 8:02 [PATCH] drivers-core: nullify private pointer on device-release Guennadi Liakhovetski
2009-10-01 13:27 ` Greg KH
2009-10-01 13:45 ` Guennadi Liakhovetski
2009-10-01 14:15 ` Greg KH
2009-10-01 14:28 ` Kay Sievers
2009-10-05 8:11 ` Guennadi Liakhovetski
2009-10-05 16:03 ` Greg KH
2009-10-05 16:14 ` Guennadi Liakhovetski
2009-10-05 16:30 ` Greg KH [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=20091005163023.GA31280@kroah.com \
--to=greg@kroah.com \
--cc=g.liakhovetski@gmx.de \
--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.