From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 18:03:44 +0200 [thread overview]
Message-ID: <520CFBE0.5070006@linutronix.de> (raw)
In-Reply-To: <20130815155508.GA14792@kroah.com>
On 08/15/2013 05:55 PM, Greg Kroah-Hartman wrote:
> 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.
As you described it later yourself: You have the same problem if you
manually unbind the platform_device from the driver while the device
node is open.
>> 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?
For this to happen you would need a refcount in uio-core which learns
that the device is gone and does not invoke any callbacks because the
device is gone. Something like you have in USB where you return 0 on
reads from ttyUSB after someone pulled the cable.
> 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?
Yes, I think so.
> 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.
okay.
>
> thanks,
>
> greg k-h
Sebastian
next prev parent reply other threads:[~2013-08-15 16:03 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
2013-08-15 16:03 ` Sebastian Andrzej Siewior [this message]
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=520CFBE0.5070006@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=Alexander.Frank@eberspaecher.com \
--cc=b.spranger@linutronix.de \
--cc=dengler@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--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.