devm_spi_register_master

devm_spi_register_master

[Julia Lawall]

Hello,

I was looking into the use of devm_spi_register_master.  This function
seems to take care of registering and unregistering, but not allocation
and freeing.  I have the impression that that is done with
spi_alloc_master and and spi_master_put, which are not managed functions.
But then I wonder how this can work?  It seems that the spi_master_put
function should remain in the probe or remove function, and then the
object could be freed before it is unregistered?

The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
devm_spi_register_master and also removes a call to spi_master_put.  By my
reasoning, this would cause a memory leak.

Am I missing something?

thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Jingoo Han]

On Tuesday, November 12, 2013 2:45 AM, Julia Lawall wrote:
> 
> Hello,
> 
> I was looking into the use of devm_spi_register_master.  This function
> seems to take care of registering and unregistering, but not allocation
> and freeing.  I have the impression that that is done with
> spi_alloc_master and and spi_master_put, which are not managed functions.
> But then I wonder how this can work?  It seems that the spi_master_put
> function should remain in the probe or remove function, and then the
> object could be freed before it is unregistered?
> 
> The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
> devm_spi_register_master and also removes a call to spi_master_put.  By my
> reasoning, this would cause a memory leak.

Hi Julia Lawall,

I already checked that the patch 2fe7e4a "spi: txx9: use
devm_spi_register_master()" is right. The call to spi_master_put()
was duplicated. So, it should be removed.

When removing the driver, the following functions are called.
: devm_spi_unregister()
       -> spi_unregister_master()
           -> device_unregister()
               -> put_device()

Also, spi_master_put() calls the following functions.
: spi_master_put()
       -> put_device()

So, put_device() is duplicated, when devm_spi_register_master()
is used. In this case, spi_master_put() can be removed.

Mark,
If I am wrong, please let me know kindly. :-)

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Julia Lawall]

On Tue, 12 Nov 2013, Jingoo Han wrote:

> On Tuesday, November 12, 2013 2:45 AM, Julia Lawall wrote:
> >
> > Hello,
> >
> > I was looking into the use of devm_spi_register_master.  This function
> > seems to take care of registering and unregistering, but not allocation
> > and freeing.  I have the impression that that is done with
> > spi_alloc_master and and spi_master_put, which are not managed functions.
> > But then I wonder how this can work?  It seems that the spi_master_put
> > function should remain in the probe or remove function, and then the
> > object could be freed before it is unregistered?
> >
> > The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
> > devm_spi_register_master and also removes a call to spi_master_put.  By my
> > reasoning, this would cause a memory leak.
>
> Hi Julia Lawall,
>
> I already checked that the patch 2fe7e4a "spi: txx9: use
> devm_spi_register_master()" is right. The call to spi_master_put()
> was duplicated. So, it should be removed.
>
> When removing the driver, the following functions are called.
> : devm_spi_unregister()
>        -> spi_unregister_master()
>            -> device_unregister()
>                -> put_device()
>
> Also, spi_master_put() calls the following functions.
> : spi_master_put()
>        -> put_device()
>
> So, put_device() is duplicated, when devm_spi_register_master()
> is used. In this case, spi_master_put() can be removed.

spi_register_master calls device_add, which seems to increment the
reference count.  So it may be that both calls to put_device are needed.
On the other hand, in that case it would be safe to invert their order.

julia

> Mark,
> If I am wrong, please let me know kindly. :-)
>
> Best regards,
> Jingoo Han
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Jingoo Han]

On Tuesday, November 12, 2013 12:19 PM, Julia Lawall wrote:
> On Tue, 12 Nov 2013, Jingoo Han wrote:
> > On Tuesday, November 12, 2013 2:45 AM, Julia Lawall wrote:
> > >
> > > I was looking into the use of devm_spi_register_master.  This function
> > > seems to take care of registering and unregistering, but not allocation
> > > and freeing.  I have the impression that that is done with
> > > spi_alloc_master and and spi_master_put, which are not managed functions.
> > > But then I wonder how this can work?  It seems that the spi_master_put
> > > function should remain in the probe or remove function, and then the
> > > object could be freed before it is unregistered?
> > >
> > > The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
> > > devm_spi_register_master and also removes a call to spi_master_put.  By my
> > > reasoning, this would cause a memory leak.
> >
> > Hi Julia Lawall,
> >
> > I already checked that the patch 2fe7e4a "spi: txx9: use
> > devm_spi_register_master()" is right. The call to spi_master_put()
> > was duplicated. So, it should be removed.
> >
> > When removing the driver, the following functions are called.
> > : devm_spi_unregister()
> >        -> spi_unregister_master()
> >            -> device_unregister()
> >                -> put_device()
> >
> > Also, spi_master_put() calls the following functions.
> > : spi_master_put()
> >        -> put_device()
> >
> > So, put_device() is duplicated, when devm_spi_register_master()
> > is used. In this case, spi_master_put() can be removed.
> 
> spi_register_master calls device_add, which seems to increment the
> reference count.  So it may be that both calls to put_device are needed.
> On the other hand, in that case it would be safe to invert their order.
> 

Hi Mark,

By the way, now I am testing s3c64xx by repeating modprobe & rmmod.
However, after s3c64xx_spi_remove() by rmmod, devm_spi_unregister()
is not called. So, at the next calling modprobe, it makes kernel panic.
On the other hand, When spi_unregister_master()& spi_master_put()
are added, the kernel panic does not happen.

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Jingoo Han]

> -----Original Message-----
> From: Julia Lawall [mailto:julia.lawall-L2FTfq7BK8M@public.gmane.org]
> Sent: Tuesday, November 12, 2013 12:19 PM
> To: Jingoo Han
> Cc: 'Mark Brown'; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: devm_spi_register_master
> 
> On Tue, 12 Nov 2013, Jingoo Han wrote:
> 
> > On Tuesday, November 12, 2013 2:45 AM, Julia Lawall wrote:
> > >
> > > Hello,
> > >
> > > I was looking into the use of devm_spi_register_master.  This function
> > > seems to take care of registering and unregistering, but not allocation
> > > and freeing.  I have the impression that that is done with
> > > spi_alloc_master and and spi_master_put, which are not managed functions.
> > > But then I wonder how this can work?  It seems that the spi_master_put
> > > function should remain in the probe or remove function, and then the
> > > object could be freed before it is unregistered?
> > >
> > > The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
> > > devm_spi_register_master and also removes a call to spi_master_put.  By my
> > > reasoning, this would cause a memory leak.
> >
> > Hi Julia Lawall,
> >
> > I already checked that the patch 2fe7e4a "spi: txx9: use
> > devm_spi_register_master()" is right. The call to spi_master_put()
> > was duplicated. So, it should be removed.
> >
> > When removing the driver, the following functions are called.
> > : devm_spi_unregister()
> >        -> spi_unregister_master()
> >            -> device_unregister()
> >                -> put_device()
> >
> > Also, spi_master_put() calls the following functions.
> > : spi_master_put()
> >        -> put_device()
> >
> > So, put_device() is duplicated, when devm_spi_register_master()
> > is used. In this case, spi_master_put() can be removed.
> 
> spi_register_master calls device_add, which seems to increment the
> reference count.  So it may be that both calls to put_device are needed.
> On the other hand, in that case it would be safe to invert their order.
> 

Then, how about the following patch submitted by Wei Yongjun?
http://www.spinics.net/lists/arm-kernel/msg286576.html

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Wei Yongjun]

On 11/15/2013 04:24 PM, Jingoo Han wrote:
>
>> -----Original Message-----
>> From: Julia Lawall [mailto:julia.lawall-L2FTfq7BK8M@public.gmane.org]
>> Sent: Tuesday, November 12, 2013 12:19 PM
>> To: Jingoo Han
>> Cc: 'Mark Brown'; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Subject: Re: devm_spi_register_master
>>
>> On Tue, 12 Nov 2013, Jingoo Han wrote:
>>
>>> On Tuesday, November 12, 2013 2:45 AM, Julia Lawall wrote:
>>>> Hello,
>>>>
>>>> I was looking into the use of devm_spi_register_master.  This function
>>>> seems to take care of registering and unregistering, but not allocation
>>>> and freeing.  I have the impression that that is done with
>>>> spi_alloc_master and and spi_master_put, which are not managed functions.
>>>> But then I wonder how this can work?  It seems that the spi_master_put
>>>> function should remain in the probe or remove function, and then the
>>>> object could be freed before it is unregistered?
>>>>
>>>> The patch 2fe7e4add3e53df7c1b97e32076f8390dd81c6b3 introduces a call to
>>>> devm_spi_register_master and also removes a call to spi_master_put.  By my
>>>> reasoning, this would cause a memory leak.
>>> Hi Julia Lawall,
>>>
>>> I already checked that the patch 2fe7e4a "spi: txx9: use
>>> devm_spi_register_master()" is right. The call to spi_master_put()
>>> was duplicated. So, it should be removed.
>>>
>>> When removing the driver, the following functions are called.
>>> : devm_spi_unregister()
>>>        -> spi_unregister_master()
>>>            -> device_unregister()
>>>                -> put_device()
>>>
>>> Also, spi_master_put() calls the following functions.
>>> : spi_master_put()
>>>        -> put_device()
>>>
>>> So, put_device() is duplicated, when devm_spi_register_master()
>>> is used. In this case, spi_master_put() can be removed.
>> spi_register_master calls device_add, which seems to increment the
>> reference count.  So it may be that both calls to put_device are needed.
>> On the other hand, in that case it would be safe to invert their order.
>>
> Then, how about the following patch submitted by Wei Yongjun?
> http://www.spinics.net/lists/arm-kernel/msg286576.html

spi_master_get() should be moved.

probe:
	spi_alloc_master        	-> Init reference count to 1	=> 1
	devm_spi_register_master	-> Not increment reference count => 1
        (It seems device_add() does not hold a reference)
remove:
	spi_master_get			-> increment reference count => 2
	devm_spi_unregister		-> decrement reference count => 1

So after remove, the reference count still 1.

If devm_spi_register_master() hold a reference, we will need
a extra spi_master_put() in remove to let master be freed.



--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Mon, Nov 11, 2013 at 09:44:56AM -0800, Julia Lawall wrote:

> I was looking into the use of devm_spi_register_master.  This function
> seems to take care of registering and unregistering, but not allocation
> and freeing.  I have the impression that that is done with

Please CC maintainers on things using the addresses from MAINTAINERS - I
didn't read these until now because you sent the mail to my work address
which mostly gets duplicates of mails to the account I normally use for
upstream so I tend not to pay so much attention to upstream mail sent
there.  There's also other Mark Brown's working on the kernel so you
might've got the wrong one!

I think this has been addressed by the patches that Wei sent or are
there still outstanding problems?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: devm_spi_register_master

[Julia Lawall]

On Sat, 16 Nov 2013, Mark Brown wrote:

> On Mon, Nov 11, 2013 at 09:44:56AM -0800, Julia Lawall wrote:
>
> > I was looking into the use of devm_spi_register_master.  This function
> > seems to take care of registering and unregistering, but not allocation
> > and freeing.  I have the impression that that is done with
>
> Please CC maintainers on things using the addresses from MAINTAINERS - I
> didn't read these until now because you sent the mail to my work address
> which mostly gets duplicates of mails to the account I normally use for
> upstream so I tend not to pay so much attention to upstream mail sent
> there.  There's also other Mark Brown's working on the kernel so you
> might've got the wrong one!

Sorry about that.  I think I took the address from a patch, which was
obviously not the right thing to do.

> I think this has been addressed by the patches that Wei sent or are
> there still outstanding problems?

I didn't have a chance to check yet.  I will take a look now.

thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Sat, Nov 16, 2013 at 07:24:20AM -0800, Julia Lawall wrote:

> Sorry about that.  I think I took the address from a patch, which was
> obviously not the right thing to do.

No, that's fine and reasonable - just add in the maintainer addresses for
the subsystem as well so maintainers see it and that'll deal with the
issue.

> > I think this has been addressed by the patches that Wei sent or are
> > there still outstanding problems?

> I didn't have a chance to check yet.  I will take a look now.

There's one of the patches Wei sent that I didn't apply yet since I'm
waiting for review from the maintainer.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: devm_spi_register_master

[Julia Lawall]

> > Then, how about the following patch submitted by Wei Yongjun?
> > http://www.spinics.net/lists/arm-kernel/msg286576.html
>
> spi_master_get() should be moved.

OK, I see now that that is the issue.

> probe:
> 	spi_alloc_master        	-> Init reference count to 1	=> 1
> 	devm_spi_register_master	-> Not increment reference count => 1
>         (It seems device_add() does not hold a reference)

Indeed.  It acquires a reference, but it releases it at the end.

> remove:
> 	spi_master_get			-> increment reference count => 2
> 	devm_spi_unregister		-> decrement reference count => 1
>
> So after remove, the reference count still 1.
>
> If devm_spi_register_master() hold a reference, we will need
> a extra spi_master_put() in remove to let master be freed.

OK, I think that everything is OK with just getting rid of the get and the
put in the remove function.  Thanks for the explanations.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: devm_spi_register_master

[Jingoo Han]

On Tuesday, November 12, 2013 3:48 PM, Jingoo Han wrote:
> Hi Mark,
> 
> By the way, now I am testing s3c64xx by repeating modprobe & rmmod.
> However, after s3c64xx_spi_remove() by rmmod, devm_spi_unregister()
> is not called. So, at the next calling modprobe, it makes kernel panic.
> On the other hand, When spi_unregister_master()& spi_master_put()
> are added, the kernel panic does not happen.

Hi Stephen Warren,

I tested your patch "spi: core: invert success test in
devm_spi_register_master" with spi-s3c64xx.ko.
I checked that the kernel panic is resolved.
Thank you for your patch. :-)

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html