2019-05-31 08:54:59

by Pavel Machek

[permalink] [raw]
Subject: devm_* vs. PROBE_DEFFER: memory leaks?

Hi!

Is devm_ supposed to work with EPROBE_DEFFER?

Probe function is now called multiple times; is memory freed between
calling probe()? Will allocations from failed probe()s remain after
the driver is inserted successfully, leaking memory?

Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (415.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2019-05-31 13:28:41

by Sebastian Reichel

[permalink] [raw]
Subject: Re: devm_* vs. PROBE_DEFFER: memory leaks?

Hi,

On Fri, May 31, 2019 at 10:52:10AM +0200, Pavel Machek wrote:
> Is devm_ supposed to work with EPROBE_DEFFER?

Sure.

> Probe function is now called multiple times;
> is memory freed between calling probe()?

Yes, EPROBE_DEFER is an error code, so devm resources
are released.

> Will allocations from failed probe()s remain after the driver is
> inserted successfully, leaking memory?

devm_ is connected to the device, not to the driver.

Since code is better than words, check drivers/base/dd.c yourself.
The relevant function name is really_probe(), interesting part for
you starts at ret = drv->probe(dev) line.

-- Sebastian


Attachments:
(No filename) (659.00 B)
signature.asc (849.00 B)
Download all attachments