[Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both

[Dmitry Torokhov]

On Fri, Jul 31, 2015 at 10:13:17AM -0700, James Bottomley wrote:
> On Fri, 2015-07-31 at 10:05 -0700, Dmitry Torokhov wrote:
> > On Fri, Jul 31, 2015 at 10:02:39AM -0700, James Bottomley wrote:
> > > On Fri, 2015-07-31 at 09:53 -0700, Christoph Hellwig wrote:
> > > > On Fri, Jul 31, 2015 at 06:34:21PM +0200, Julia Lawall wrote:
> > > > > How is this different from the free happening explicitly in the remove
> > > > > function?
> > > > 
> > > > It's not.  The real problem is that people don't understand life time
> > > > rules and expect magic interfaces to fix it for them.
> > > 
> > > So surely the rule is that we do this in module removal.  That doesn't
> > > get called until last put on the module and that can't happen (or
> > > shouldn't happen) while userspace is holding open one of the /sys
> > > or /proc interfaces (usually those objects hold a reference on something
> > > within the driver to prevent this).
> > > 
> > > There is an alternative way of handling this:  that would be to detach
> > > the file from the backing interface at _del time, so sysfs/kernfs would
> > > take over the interface and return -ENODEV or something  meaning we
> > > could tear down the module even if there was an open interface file.
> > > I'm not advocating this as a solution because I can already see the
> > > problems (like how do you switch interfaces atomically) but if this
> > > really is a serious problem, we should explore alternative solutions.
> > 
> > Tejun already done such "switching" for sysfs so it should be possible,
> > however (blasphemy!) there are other entities than files that also may
> > have different lifetime rules that live past device unbinding.
> 
> By unbinding do you mean when the unbind is called, which is fine, the
> interface handler is still there, or when the final module put is
> called, which is not fine because that's a lifetime problem.  In the
> latter case we need a hunting expedition to have them all caught and
> shot.

I was talking about former because module is normally stays pinned if it
implements file_operations and will not be unpinned until last release
on file (device) is called.

Thanks.

-- 
Dmitry