Subject: em28xx leaks
Date: Fri, 27 Jan 2012 13:21:50 -0600
From: Todd Squires <squirest@xxxxxxx>
Organisation: Core Technologies
To: rankincj@xxxxxxxxx
Hi Chris,
I've recently started using an em28xx, and have run into a memory
leak in the 3.2.1 kernel.
Poking around the Internet, I found that you've been recently
submitting patches for this driver.
I have a program which opens a V4L2 device, configures it, reads a
frame, then closes the device and exits. This program runs every
minute or so. After a short time, I noticed my Linux machine
complaining that vmalloc was out of memory.
Digging into the driver, I found the problem is in em28xx_v4l2_close.
Specifically, this test is not succeeding, and videobuf_stop is
not being called when it should be:
if (res_check(fh, EM28XX_RESOURCE_VIDEO)) {
videobuf_stop(&fh->vb_vidq);
res_free(fh, EM28XX_RESOURCE_VIDEO);
}
After failing to call videobuf_stop, em28xx_v4l2_close
then calls this:
videobuf_mmap_free(&fh->vb_vidq);
and it fails to deallocate because it sees "fh->vb_vidq.reading" is
still set. This leaks lots of memory.
I hacked around the problem by sticking this in the code:
if (fh->vb_vidq.reading)
videobuf_read_stop(&fh->vb_vidq);
However, the proper fix is to go through the code and work out
why EM28XX_RESOURCE_VIDEO is not getting set as it should be.
Since I'm not terribly familiar with the driver, I figured I'd point
this issue out to you. If you can fix it, please let me know.
Otherwise I'll dig deeper and take care of it properly on my end
when I get some free time.
Cheers,
-Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
