All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Benedikt Spranger <b.spranger@linutronix.de>,
	netdev@vger.kernel.org,
	Alexander Frank <Alexander.Frank@eberspaecher.com>,
	"Hans J. Koch" <hjk@hansjkoch.de>,
	Holger Dengler <dengler@linutronix.de>
Subject: Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
Date: Thu, 15 Aug 2013 08:55:08 -0700	[thread overview]
Message-ID: <20130815155508.GA14792@kroah.com> (raw)
In-Reply-To: <520C8EC9.6040603@linutronix.de>

On Thu, Aug 15, 2013 at 10:18:17AM +0200, Sebastian Andrzej Siewior wrote:
> On 08/15/2013 10:09 AM, Greg Kroah-Hartman wrote:
> > Do you have a specific example of an in-tree UIO driver that has this
> > problem that I can look at to try to understand this better?
> 
> grep for "uio_pdrv" and you find a few devices in arm and sh tree. Each
> one is created once at boot time and never removed. With mfd the device
> can be removed.

But that's a "platform" device, for a resource that is described as not
going away.

If this is really a mfd device, then make your uio driver a mfd driver,
not a platform driver for a resource that isn't under your control.

> If you look now at uio_write() then you will notice that it will
> deference idev->info->irqcontrol but once the device is gone the memory
> starting at info is gone, not to mention the code behind irqcontrol.

It sounds like the wrong uio driver is binding to this device, fix the
uio driver and you should be fine, right?

A module reference count will not "save" you from a device going away,
only a code chunk going away.  That is why no other subsystem has this
type of thing.  If you dynamically remove the mfd device, but not remove
the module (i.e. through the sysfs files to do that), then you would
still have this same problem, right?

There's a reason the driver core doesn't deal with module reference
counts, it's not the proper thing for devices.  So I'm not willing to
add it to the UIO code either, as it's not the correct thing for it.

thanks,

greg k-h

  reply	other threads:[~2013-08-15 15:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13  9:08 [PATCH 0/7] add FlexRay support Benedikt Spranger
2013-08-13  9:08 ` Benedikt Spranger
2013-08-13  9:08 ` [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading Benedikt Spranger
2013-08-13 17:48   ` Greg Kroah-Hartman
2013-08-14  7:19     ` Benedikt Spranger
2013-08-14 16:33       ` Greg Kroah-Hartman
2013-08-15  6:42         ` Benedikt Spranger
2013-08-15  6:59           ` Greg Kroah-Hartman
2013-08-15  7:27             ` Benedikt Spranger
2013-08-15  8:09               ` Greg Kroah-Hartman
2013-08-15  8:18                 ` Sebastian Andrzej Siewior
2013-08-15 15:55                   ` Greg Kroah-Hartman [this message]
2013-08-15 16:03                     ` Sebastian Andrzej Siewior
2013-08-15 16:42                       ` Greg Kroah-Hartman
2013-08-15 16:54                         ` Sebastian Andrzej Siewior
2013-08-15 17:13                           ` Greg Kroah-Hartman
2013-08-13  9:08 ` [PATCH 2/7] uio: Allow to create custom UIO attributes Benedikt Spranger
2013-08-13 17:54   ` Greg Kroah-Hartman
2013-08-13  9:08 ` [PATCH 3/7] mfd: core: copy DMA mask and params from parent Benedikt Spranger
2013-08-13 10:03   ` Lee Jones
2013-08-13  9:08 ` [PATCH 4/7] mfd: add MFD based flexcard driver Benedikt Spranger
2013-08-13  9:55   ` Lee Jones
2013-08-14  8:12     ` Benedikt Spranger
2013-08-14  9:45       ` Lee Jones
2013-08-13  9:08 ` [PATCH 5/7] clocksource: Add flexcard support Benedikt Spranger
2013-08-13  9:08 ` [PATCH 6/7] net: add the AF_FLEXRAY protocol Benedikt Spranger
2013-08-18 18:50   ` Oliver Hartkopp
2013-08-13  9:08 ` [PATCH 7/7] net: add a flexray driver Benedikt Spranger

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=20130815155508.GA14792@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Alexander.Frank@eberspaecher.com \
    --cc=b.spranger@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=dengler@linutronix.de \
    --cc=hjk@hansjkoch.de \
    --cc=netdev@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.