Dear Guenter Roeck,

On Wed, Aug 01, 2012 at 02:28:40PM +0800, Shawn Guo wrote:

quoted

On Tue, Jul 31, 2012 at 10:42:28PM -0700, Guenter Roeck wrote:

quoted

On Wed, Aug 01, 2012 at 01:58:56PM +0800, Shawn Guo wrote:

quoted

On Tue, Jul 31, 2012 at 10:29:47PM -0700, Guenter Roeck wrote:

quoted

Anyone up for writing some patches ? If not, I'll do it.

Go ahead.

Ok, will do. It isn't that simple, actually, since at least some of the
drivers also call spi_master_get(), and thus need two calls to
spi_master_put() (or a call to spi_master_put and a call to kfree).

Hmm, are you saying that there must be a spi_master_put call matching
spi_alloc_master?  I think we only need to have spi_master_get and
spi_master_put matched.

Yes, I think that may be so. Of course, I may be wrong, but ultimately that
is what almost all drivers do in the probe error path. Some of the drivers
do it in the remove path as well, though many don't. I suspect that all
drivers using spi_alloc_master() which do not call spi_master_put() in the
remove function may have a memory leak.

CCing Mark.

Someone who knows the spi infrastructure better than I should have a closer
look, though. The question is really quite simple: For example, in
spi-atmel.c, how is the allocated master freed in the _remove function ?
If it doesn't need the call to spi_master_put(), why do, for example,
spi-stmp.c or spi-mpc52xx.c call it ?

On the other side, I must admit I am getting more and more confused after
looking into the code. For example, the probe function error path in
spi-mpc52xx.c accesses the master's devdata after the call to
spi_master_put(). If spi_master_put() frees the memory as we think it
does, the code would access freed memory. The same happens in the remove
path. And spi_master_put() is not always called, meaning there is either a
memory leak or I am completely confused.

I'll poke through the stuff later if you won't get your answers (later == around 
tomorrow)

Thanks,
Guenter

Best regards,
Marek Vasut