Re: kmemleak report on isp1763 and sierra MC8705
On Tue, 2012-11-20 at 17:15 -0800, Greg Kroah-Hartman wrote:
> On Wed, Nov 14, 2012 at 06:52:18PM +0100, Johan Hovold wrote:
> > On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote:
> > > On 10/11/12 09:30 AM, Johan Hovold wrote:
> > > Hi Johan,
> > >
> > > > There was a reference-count fix for the probe error path that went in to
> > > > v3.5. Haven't read all the details on how you trigger your leak, but at
> > > > the face of it, it could be related.
> > > >
> > > > Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
> > > > usb_serial_probe errors). If related, you should be seeing "Ignoring
> > > > blacklisted interface #n" messages when you enable debug (e.g. #define
> > > > DEBUG) in the sierra driver.
> > >
> > > That was it! Thanks so much for the research.
> > > I can apply it cleanly to 3.0.22 and see usb_release_dev() being
> > > called and thus no more kmemleak.
> > >
> > > >
> > > > Greg, it seems to me that the fix referred to above should be backported
> > > > to the earlier stable trees either way.
> > > I would vote "yes" for this also.
> > >
> > > While my setup circumstances may be a corner case, (modem kept
> > > resetting to re-establish PPP connection) it was leaking 1192 bytes
> > > per occurrence.
> >
> > The leak affects every failed probe, for example due to blacklisted
> > interfaces which is quite common, so commit 0658a3366db7 ("usb: use
> > usb_serial_put in usb_serial_probe errors) should be backported to the
> > <= 3.4 stable trees.
>
> Thanks, now applied.
Also queued up for 3.2.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
Re: kmemleak report on isp1763 and sierra MC8705
On Tue, 2012-11-20 at 17:15 -0800, Greg Kroah-Hartman wrote: On Wed, Nov 14, 2012 at 06:52:18PM +0100, Johan Hovold wrote: On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote: On 10/11/12 09:30 AM, Johan Hovold wrote: Hi Johan, There was a reference-count fix for the probe error path that went in to v3.5. Haven't read all the details on how you trigger your leak, but at the face of it, it could be related. Have a look at 0658a3366db7e27fa (usb: use usb_serial_put in usb_serial_probe errors). If related, you should be seeing Ignoring blacklisted interface #n messages when you enable debug (e.g. #define DEBUG) in the sierra driver. That was it! Thanks so much for the research. I can apply it cleanly to 3.0.22 and see usb_release_dev() being called and thus no more kmemleak. Greg, it seems to me that the fix referred to above should be backported to the earlier stable trees either way. I would vote yes for this also. While my setup circumstances may be a corner case, (modem kept resetting to re-establish PPP connection) it was leaking 1192 bytes per occurrence. The leak affects every failed probe, for example due to blacklisted interfaces which is quite common, so commit 0658a3366db7 (usb: use usb_serial_put in usb_serial_probe errors) should be backported to the = 3.4 stable trees. Thanks, now applied. Also queued up for 3.2. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Re: kmemleak report on isp1763 and sierra MC8705
On Wed, Nov 14, 2012 at 06:52:18PM +0100, Johan Hovold wrote:
> On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote:
> > On 10/11/12 09:30 AM, Johan Hovold wrote:
> > Hi Johan,
> >
> > > There was a reference-count fix for the probe error path that went in to
> > > v3.5. Haven't read all the details on how you trigger your leak, but at
> > > the face of it, it could be related.
> > >
> > > Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
> > > usb_serial_probe errors). If related, you should be seeing "Ignoring
> > > blacklisted interface #n" messages when you enable debug (e.g. #define
> > > DEBUG) in the sierra driver.
> >
> > That was it! Thanks so much for the research.
> > I can apply it cleanly to 3.0.22 and see usb_release_dev() being
> > called and thus no more kmemleak.
> >
> > >
> > > Greg, it seems to me that the fix referred to above should be backported
> > > to the earlier stable trees either way.
> > I would vote "yes" for this also.
> >
> > While my setup circumstances may be a corner case, (modem kept
> > resetting to re-establish PPP connection) it was leaking 1192 bytes
> > per occurrence.
>
> The leak affects every failed probe, for example due to blacklisted
> interfaces which is quite common, so commit 0658a3366db7 ("usb: use
> usb_serial_put in usb_serial_probe errors) should be backported to the
> <= 3.4 stable trees.
Thanks, now applied.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Wed, Nov 14, 2012 at 06:52:18PM +0100, Johan Hovold wrote: On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote: On 10/11/12 09:30 AM, Johan Hovold wrote: Hi Johan, There was a reference-count fix for the probe error path that went in to v3.5. Haven't read all the details on how you trigger your leak, but at the face of it, it could be related. Have a look at 0658a3366db7e27fa (usb: use usb_serial_put in usb_serial_probe errors). If related, you should be seeing Ignoring blacklisted interface #n messages when you enable debug (e.g. #define DEBUG) in the sierra driver. That was it! Thanks so much for the research. I can apply it cleanly to 3.0.22 and see usb_release_dev() being called and thus no more kmemleak. Greg, it seems to me that the fix referred to above should be backported to the earlier stable trees either way. I would vote yes for this also. While my setup circumstances may be a corner case, (modem kept resetting to re-establish PPP connection) it was leaking 1192 bytes per occurrence. The leak affects every failed probe, for example due to blacklisted interfaces which is quite common, so commit 0658a3366db7 (usb: use usb_serial_put in usb_serial_probe errors) should be backported to the = 3.4 stable trees. Thanks, now applied. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote:
> On 10/11/12 09:30 AM, Johan Hovold wrote:
> Hi Johan,
>
> > There was a reference-count fix for the probe error path that went in to
> > v3.5. Haven't read all the details on how you trigger your leak, but at
> > the face of it, it could be related.
> >
> > Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
> > usb_serial_probe errors). If related, you should be seeing "Ignoring
> > blacklisted interface #n" messages when you enable debug (e.g. #define
> > DEBUG) in the sierra driver.
>
> That was it! Thanks so much for the research.
> I can apply it cleanly to 3.0.22 and see usb_release_dev() being
> called and thus no more kmemleak.
>
> >
> > Greg, it seems to me that the fix referred to above should be backported
> > to the earlier stable trees either way.
> I would vote "yes" for this also.
>
> While my setup circumstances may be a corner case, (modem kept
> resetting to re-establish PPP connection) it was leaking 1192 bytes
> per occurrence.
The leak affects every failed probe, for example due to blacklisted
interfaces which is quite common, so commit 0658a3366db7 ("usb: use
usb_serial_put in usb_serial_probe errors) should be backported to the
<= 3.4 stable trees.
Thanks for reporting,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 10/11/12 09:30 AM, Johan Hovold wrote:
Hi Johan,
There was a reference-count fix for the probe error path that went in to
v3.5. Haven't read all the details on how you trigger your leak, but at
the face of it, it could be related.
Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
usb_serial_probe errors). If related, you should be seeing "Ignoring
blacklisted interface #n" messages when you enable debug (e.g. #define
DEBUG) in the sierra driver.
That was it! Thanks so much for the research.
I can apply it cleanly to 3.0.22 and see usb_release_dev() being called and
thus no more kmemleak.
Greg, it seems to me that the fix referred to above should be backported
to the earlier stable trees either way.
I would vote "yes" for this also.
While my setup circumstances may be a corner case, (modem kept resetting to
re-establish PPP connection)
it was leaking 1192 bytes per occurrence.
Thanks for everyone's time.
-- Richard Retanubun.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 10/11/12 09:30 AM, Johan Hovold wrote: Hi Johan, There was a reference-count fix for the probe error path that went in to v3.5. Haven't read all the details on how you trigger your leak, but at the face of it, it could be related. Have a look at 0658a3366db7e27fa (usb: use usb_serial_put in usb_serial_probe errors). If related, you should be seeing Ignoring blacklisted interface #n messages when you enable debug (e.g. #define DEBUG) in the sierra driver. That was it! Thanks so much for the research. I can apply it cleanly to 3.0.22 and see usb_release_dev() being called and thus no more kmemleak. Greg, it seems to me that the fix referred to above should be backported to the earlier stable trees either way. I would vote yes for this also. While my setup circumstances may be a corner case, (modem kept resetting to re-establish PPP connection) it was leaking 1192 bytes per occurrence. Thanks for everyone's time. -- Richard Retanubun. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Wed, Nov 14, 2012 at 12:12:01PM -0500, Richard Retanubun wrote: On 10/11/12 09:30 AM, Johan Hovold wrote: Hi Johan, There was a reference-count fix for the probe error path that went in to v3.5. Haven't read all the details on how you trigger your leak, but at the face of it, it could be related. Have a look at 0658a3366db7e27fa (usb: use usb_serial_put in usb_serial_probe errors). If related, you should be seeing Ignoring blacklisted interface #n messages when you enable debug (e.g. #define DEBUG) in the sierra driver. That was it! Thanks so much for the research. I can apply it cleanly to 3.0.22 and see usb_release_dev() being called and thus no more kmemleak. Greg, it seems to me that the fix referred to above should be backported to the earlier stable trees either way. I would vote yes for this also. While my setup circumstances may be a corner case, (modem kept resetting to re-establish PPP connection) it was leaking 1192 bytes per occurrence. The leak affects every failed probe, for example due to blacklisted interfaces which is quite common, so commit 0658a3366db7 (usb: use usb_serial_put in usb_serial_probe errors) should be backported to the = 3.4 stable trees. Thanks for reporting, Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Fri, Nov 9, 2012 at 11:14 PM, Richard Retanubun
wrote:
> On 29/10/12 06:14 PM, Alan Stern wrote:
>>
>> On Mon, 29 Oct 2012, Richard Retanubun wrote:
>>>
>>> Focusing down on one of the dumps:
>>>
>>> unreferenced object 0xd3849740 (size 8):
>>> comm "khubd", pid 1026, jiffies 232553037 (age 506.597s)
>>> hex dump (first 8 bytes):
>>> 4d 43 38 37 30 35 00 00 MC8705..
>>> backtrace:
>>> [] usb_cache_string+0x74/0xac [usbcore]
>>> [] usb_enumerate_device+0x44/0xf8 [usbcore]
>>> [] usb_new_device+0x3c/0x13c [usbcore]
>>> [] hub_thread+0xc8c/0x1544 [usbcore]
>>> [] kthread+0x7c/0x80
>>> [] kernel_thread+0x4c/0x68
>>>
>>> I have a small question. How does the memory kmalloc-ed() in
>>> usb_cache_string is supposed to be released?
>>> (during usb_serial_disconnect()?)
>>
>>
>> It doesn't get released during usb_serial_disconnect(). It gets
>> released during usb_release_dev() in drivers/usb/core/usb.c.
>>
>>> Is the sierra driver is supposed to participate
>>> in the tear down process (in sierra_release() maybe) and not doing
>>> something that is expected?
>>
>>
>> Probably not.
>>
>>> I am still missing the link between the actions done by the hub_thread()
>>> for the caching the stings
>>> and the sierra driver code.
>>
>>
>> They aren't all that closely related.
>>
>> usb_release_dev() won't be called until all references to the USB
>> device have been dropped. Maybe there's an extra reference hanging
>> around.
>>
>> Alan Stern
>>
> Thanks a lot for the hint Alan.
>
> I added a dev_dbg print in usb_release_dev() and saw that in the builds
> where there is a leak, this was simply never called!
> the last line printed in a trace with all dev_dbg on is this
> "usb_disable_device nuking all URBs"
> When the sierra modem is unplugged, the cleanup sequence never calls
> usb_release_dev() (on PL2303 it always calls usb_release_dev()
>
> This is the current state of versions from linux-stable
>
> 3.0.y (3.0.51) - Have the issue
> 3.2.y (3.2.33) - Have the issue
> 3.4.y (3.4.18) - Have the issue
> 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata
> patches is not backported yet)
> 3.6.y (3.6.6) - Does not have the issue
>
> So a diff between 3.4.y and 3.5.y ought to narrow it down further.
>
> I am posting just in case someone recalls a particular patch I should be
> trying out first...
There was a reference-count fix for the probe error path that went in to
v3.5. Haven't read all the details on how you trigger your leak, but at
the face of it, it could be related.
Have a look at 0658a3366db7e27fa ("usb: use usb_serial_put in
usb_serial_probe errors). If related, you should be seeing "Ignoring
blacklisted interface #n" messages when you enable debug (e.g. #define
DEBUG) in the sierra driver.
Greg, it seems to me that the fix referred to above should be backported
to the earlier stable trees either way.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Fri, Nov 9, 2012 at 11:14 PM, Richard Retanubun richardretanu...@ruggedcom.com wrote: On 29/10/12 06:14 PM, Alan Stern wrote: On Mon, 29 Oct 2012, Richard Retanubun wrote: Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm khubd, pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [e30efd74] usb_cache_string+0x74/0xac [usbcore] [e30e77bc] usb_enumerate_device+0x44/0xf8 [usbcore] [e30e7aa0] usb_new_device+0x3c/0x13c [usbcore] [e30e9824] hub_thread+0xc8c/0x1544 [usbcore] [c0043aa8] kthread+0x7c/0x80 [c000ed48] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? Probably not. I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern Thanks a lot for the hint Alan. I added a dev_dbg print in usb_release_dev() and saw that in the builds where there is a leak, this was simply never called! the last line printed in a trace with all dev_dbg on is this usb_disable_device nuking all URBs When the sierra modem is unplugged, the cleanup sequence never calls usb_release_dev() (on PL2303 it always calls usb_release_dev() This is the current state of versions from linux-stable 3.0.y (3.0.51) - Have the issue 3.2.y (3.2.33) - Have the issue 3.4.y (3.4.18) - Have the issue 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata patches is not backported yet) 3.6.y (3.6.6) - Does not have the issue So a diff between 3.4.y and 3.5.y ought to narrow it down further. I am posting just in case someone recalls a particular patch I should be trying out first... There was a reference-count fix for the probe error path that went in to v3.5. Haven't read all the details on how you trigger your leak, but at the face of it, it could be related. Have a look at 0658a3366db7e27fa (usb: use usb_serial_put in usb_serial_probe errors). If related, you should be seeing Ignoring blacklisted interface #n messages when you enable debug (e.g. #define DEBUG) in the sierra driver. Greg, it seems to me that the fix referred to above should be backported to the earlier stable trees either way. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 29/10/12 06:14 PM, Alan Stern wrote: On Mon, 29 Oct 2012, Richard Retanubun wrote: Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm "khubd", pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [] usb_cache_string+0x74/0xac [usbcore] [] usb_enumerate_device+0x44/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? Probably not. I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern Thanks a lot for the hint Alan. I added a dev_dbg print in usb_release_dev() and saw that in the builds where there is a leak, this was simply never called! the last line printed in a trace with all dev_dbg on is this "usb_disable_device nuking all URBs" When the sierra modem is unplugged, the cleanup sequence never calls usb_release_dev() (on PL2303 it always calls usb_release_dev() This is the current state of versions from linux-stable 3.0.y (3.0.51) - Have the issue 3.2.y (3.2.33) - Have the issue 3.4.y (3.4.18) - Have the issue 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata patches is not backported yet) 3.6.y (3.6.6) - Does not have the issue So a diff between 3.4.y and 3.5.y ought to narrow it down further. I am posting just in case someone recalls a particular patch I should be trying out first... -- RR -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 29/10/12 06:14 PM, Alan Stern wrote: On Mon, 29 Oct 2012, Richard Retanubun wrote: Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm khubd, pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [e30efd74] usb_cache_string+0x74/0xac [usbcore] [e30e77bc] usb_enumerate_device+0x44/0xf8 [usbcore] [e30e7aa0] usb_new_device+0x3c/0x13c [usbcore] [e30e9824] hub_thread+0xc8c/0x1544 [usbcore] [c0043aa8] kthread+0x7c/0x80 [c000ed48] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? Probably not. I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern Thanks a lot for the hint Alan. I added a dev_dbg print in usb_release_dev() and saw that in the builds where there is a leak, this was simply never called! the last line printed in a trace with all dev_dbg on is this usb_disable_device nuking all URBs When the sierra modem is unplugged, the cleanup sequence never calls usb_release_dev() (on PL2303 it always calls usb_release_dev() This is the current state of versions from linux-stable 3.0.y (3.0.51) - Have the issue 3.2.y (3.2.33) - Have the issue 3.4.y (3.4.18) - Have the issue 3.5.y (3.5.7) - Does not have the issue (but leaks because the portdata patches is not backported yet) 3.6.y (3.6.6) - Does not have the issue So a diff between 3.4.y and 3.5.y ought to narrow it down further. I am posting just in case someone recalls a particular patch I should be trying out first... -- RR -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Mon, 29 Oct 2012, Richard Retanubun wrote: > do the disconnect without actually removing the power to the device. > I tried "echo 1 > /sys/bus/usb/drivers/usb/2-1.2/remove" and then take down > the power > but this produced the same leak signature even before I take down the power. > > Update on trigger to problem > > This will happen as the modem is powered down and /dev/ttyUSB from sierra is > teared down > either by powering it off/removing it, or sending at!reset. > > It does not happen when the same thing is done using a simple usb to serial > converter (pl2303) > > Focusing down on one of the dumps: > > unreferenced object 0xd3849740 (size 8): >comm "khubd", pid 1026, jiffies 232553037 (age 506.597s) >hex dump (first 8 bytes): > 4d 43 38 37 30 35 00 00 MC8705.. >backtrace: > [] usb_cache_string+0x74/0xac [usbcore] > [] usb_enumerate_device+0x44/0xf8 [usbcore] > [] usb_new_device+0x3c/0x13c [usbcore] > [] hub_thread+0xc8c/0x1544 [usbcore] > [] kthread+0x7c/0x80 > [] kernel_thread+0x4c/0x68 > > I have a small question. How does the memory kmalloc-ed() in usb_cache_string > is supposed to be released? > (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. > Is the sierra driver is supposed to participate > in the tear down process (in sierra_release() maybe) and not doing something > that is expected? Probably not. > I am still missing the link between the actions done by the hub_thread() for > the caching the stings > and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Mon, Oct 29, 2012 at 04:47:04PM -0400, Richard Retanubun wrote: > On 26/10/12 07:35 PM, Greg KH wrote: > >On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: > >>Hi Guys, > >> > >>I am debugging a reported kmemleak involving a sierra wireless MC8705 > >>connected > >>through isp1763 on powerpc linux-3.0.22 > > > >Does this also happen on 3.6.3? > > > >thanks, > > > >greg k-h > > Hi Greg, > > Unfortunately, it is not trivial for us to update the kernel on this platform, > Is there a specific experiment/patch I should look at for 3.0.22? I have no idea, given that 3.0.22 is based on 18 month old kernel, tens of thousands of patches ago. You are on your own here, sorry. Best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 26/10/12 07:35 PM, Greg KH wrote: On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: Hi Guys, I am debugging a reported kmemleak involving a sierra wireless MC8705 connected through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, greg k-h Hi Greg, Unfortunately, it is not trivial for us to update the kernel on this platform, Is there a specific experiment/patch I should look at for 3.0.22? I will be attempting to use 3.6.3 on another platform, but this may take some time. I am thinking there may be an action that can be done at /sysfs or /procfs to do the disconnect without actually removing the power to the device. I tried "echo 1 > /sys/bus/usb/drivers/usb/2-1.2/remove" and then take down the power but this produced the same leak signature even before I take down the power. Update on trigger to problem This will happen as the modem is powered down and /dev/ttyUSB from sierra is teared down either by powering it off/removing it, or sending at!reset. It does not happen when the same thing is done using a simple usb to serial converter (pl2303) Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm "khubd", pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [] usb_cache_string+0x74/0xac [usbcore] [] usb_enumerate_device+0x44/0xf8 [usbcore] [] usb_new_device+0x3c/0x13c [usbcore] [] hub_thread+0xc8c/0x1544 [usbcore] [] kthread+0x7c/0x80 [] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. Thanks a lot for your time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On 26/10/12 07:35 PM, Greg KH wrote: On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: Hi Guys, I am debugging a reported kmemleak involving a sierra wireless MC8705 connected through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, greg k-h Hi Greg, Unfortunately, it is not trivial for us to update the kernel on this platform, Is there a specific experiment/patch I should look at for 3.0.22? I will be attempting to use 3.6.3 on another platform, but this may take some time. I am thinking there may be an action that can be done at /sysfs or /procfs to do the disconnect without actually removing the power to the device. I tried echo 1 /sys/bus/usb/drivers/usb/2-1.2/remove and then take down the power but this produced the same leak signature even before I take down the power. Update on trigger to problem This will happen as the modem is powered down and /dev/ttyUSB from sierra is teared down either by powering it off/removing it, or sending at!reset. It does not happen when the same thing is done using a simple usb to serial converter (pl2303) Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm khubd, pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [e30efd74] usb_cache_string+0x74/0xac [usbcore] [e30e77bc] usb_enumerate_device+0x44/0xf8 [usbcore] [e30e7aa0] usb_new_device+0x3c/0x13c [usbcore] [e30e9824] hub_thread+0xc8c/0x1544 [usbcore] [c0043aa8] kthread+0x7c/0x80 [c000ed48] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. Thanks a lot for your time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Mon, Oct 29, 2012 at 04:47:04PM -0400, Richard Retanubun wrote: On 26/10/12 07:35 PM, Greg KH wrote: On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: Hi Guys, I am debugging a reported kmemleak involving a sierra wireless MC8705 connected through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, greg k-h Hi Greg, Unfortunately, it is not trivial for us to update the kernel on this platform, Is there a specific experiment/patch I should look at for 3.0.22? I have no idea, given that 3.0.22 is based on 18 month old kernel, tens of thousands of patches ago. You are on your own here, sorry. Best of luck, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Mon, 29 Oct 2012, Richard Retanubun wrote: do the disconnect without actually removing the power to the device. I tried echo 1 /sys/bus/usb/drivers/usb/2-1.2/remove and then take down the power but this produced the same leak signature even before I take down the power. Update on trigger to problem This will happen as the modem is powered down and /dev/ttyUSB from sierra is teared down either by powering it off/removing it, or sending at!reset. It does not happen when the same thing is done using a simple usb to serial converter (pl2303) Focusing down on one of the dumps: unreferenced object 0xd3849740 (size 8): comm khubd, pid 1026, jiffies 232553037 (age 506.597s) hex dump (first 8 bytes): 4d 43 38 37 30 35 00 00 MC8705.. backtrace: [e30efd74] usb_cache_string+0x74/0xac [usbcore] [e30e77bc] usb_enumerate_device+0x44/0xf8 [usbcore] [e30e7aa0] usb_new_device+0x3c/0x13c [usbcore] [e30e9824] hub_thread+0xc8c/0x1544 [usbcore] [c0043aa8] kthread+0x7c/0x80 [c000ed48] kernel_thread+0x4c/0x68 I have a small question. How does the memory kmalloc-ed() in usb_cache_string is supposed to be released? (during usb_serial_disconnect()?) It doesn't get released during usb_serial_disconnect(). It gets released during usb_release_dev() in drivers/usb/core/usb.c. Is the sierra driver is supposed to participate in the tear down process (in sierra_release() maybe) and not doing something that is expected? Probably not. I am still missing the link between the actions done by the hub_thread() for the caching the stings and the sierra driver code. They aren't all that closely related. usb_release_dev() won't be called until all references to the USB device have been dropped. Maybe there's an extra reference hanging around. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: > Hi Guys, > > I am debugging a reported kmemleak involving a sierra wireless MC8705 > connected > through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmemleak report on isp1763 and sierra MC8705
On Fri, Oct 26, 2012 at 05:57:23PM -0400, Richard Retanubun wrote: Hi Guys, I am debugging a reported kmemleak involving a sierra wireless MC8705 connected through isp1763 on powerpc linux-3.0.22 Does this also happen on 3.6.3? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
