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

James Bottomley James.Bottomley at HansenPartnership.com
Fri Jul 31 17:13:17 UTC 2015


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.

James





More information about the Ksummit-discuss mailing list