V4L/DVB (10305): videobuf-vmalloc: Fix: videobuf memory were never freed

videobuf_vmalloc_free() is never freeing the video buffer memory. Due to
that, after multiple open/closes, user can suffer a panic:

Kernel BUG at mm/slab.c:2650
invalid opcode: 0000 [1] SMP
last sysfs file: /class/video4linux/video0/dev
CPU 4
Modules linked in: vivi(U) videodev(U) v4l1_compat(U) v4l2_compat_ioctl32(U) videobuf_vmalloc(U) videobuf_core(U) ipv6 xfrm_nalgo autofs4 vmnet(U) vmblock(U) vmci(U) vmmon(U) ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand dm_mirror dm_log dm_multipath scsi_dh dm_mod video backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp testmgr_cipher testmgr aead crypto_blkcipher crypto_algapi crypto_api arc4 snd_hda_intel nvidia(PFU) snd_seq_dummy snd_seq_oss snd_seq_midi_event rt73usb crc_itu_t snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss tg3 sr_mod snd_pcm snd_timer snd_page_alloc snd_hwdep pcspkr rt2500usb cdrom rt2x00usb rt2x00lib libphy snd parport_pc soundcore shpchp serio_raw i2c_i801 i5400_edac parport ata_piix sg mac80211 edac_mc i2c_core cfg80211 ahci libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 6215, comm: v4l-stress-buff Tainted: PF     2.6.18-118.el5 #1
RIP: 0010:[<ffffffff80017506>]  [<ffffffff80017506>] cache_grow+0x1e/0x395
RSP: 0018:ffff810128a35d28  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 00000000000080d0 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 00000000000080d0 RDI: ffff8101042d8340
RBP: ffff8101042ce5e0 R08: ffff81012fc1e8c0 R09: ffff8101042eac00
R10: 0000000000000000 R11: ffffffff882a5139 R12: ffff8101042d8340
R13: ffff8101042ce5c0 R14: 0000000000000000 R15: ffff8101042d8340
FS:  0000000000000000(0000) GS:ffff81012fc24d40(0063) knlGS:00000000f7f706c0
CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000f7f9a000 CR3: 0000000117ad0000 CR4: 00000000000006e0
Process v4l-stress-buff (pid: 6215, threadinfo ffff810128a34000, task ffff810128fcb820)
Stack:  ffffc20012a39000 0000004415173ff8 ffff810000011c10 000280d200000000
 0000000000000002 00000000ffffffff ffff8101042ce5e0 ffff81012fc1e8c0
 ffff8101042ce5c0 000000000000000c ffff8101042d8340 ffffffff8005bdde
Call Trace:
 [<ffffffff8005bdde>] cache_alloc_refill+0x136/0x186
 [<ffffffff800d7822>] kmem_cache_alloc_node+0x98/0xb2
 [<ffffffff800cda1f>] __vmalloc_area_node+0x62/0x153
 [<ffffffff800cdd65>] vmalloc_user+0x15/0x50
 [<ffffffff882a521f>] :videobuf_vmalloc:__videobuf_iolock+0xe6/0x155
 [<ffffffff8838f958>] :vivi:buffer_prepare+0xb9/0xe6
 [<ffffffff882981f3>] :videobuf_core:__videobuf_read_start+0xa2/0x10f
 [<ffffffff882983e6>] :videobuf_core:videobuf_read_stream+0x9c/0x1f3
 [<ffffffff8000b3f3>] vfs_read+0xcb/0x171
 [<ffffffff80011967>] sys_read+0x45/0x6e
 [<ffffffff8006149b>] sysenter_do_call+0x1b/0x67

Code: 0f 0b 68 af 1e 2a 80 c2 5a 0a f6 c7 20 0f 85 53 03 00 00 89
RIP  [<ffffffff80017506>] cache_grow+0x1e/0x395
 RSP <ffff810128a35d28>
 <0>Kernel panic - not syncing: Fatal exception

Thanks to Douglas Schilling Landgraf <dougsland@gmail.com> for writing a
stress tool for testing and to Robert Krakora <rob.krakora@messagenetsystems.com>
to trace the code and discover the point where the bug were happening.
Thanks also to Magnus Damm <damm@igel.co.jp> that provided us a fix for
a similar bug on videobuf-dma-contig.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/video/videobuf-vmalloc.c b/drivers/media/video/videobuf-vmalloc.c
index be65a2fb39762551d8d30c56634cf273aa909636..30ae30f99ccc38dd6f10bd0b0685e7e881111099 100644 (file)
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -425,7 +425,7 @@ void videobuf_vmalloc_free (struct videobuf_buffer *buf)
           So, it should free memory only if the memory were allocated for
           read() operation.
         */
-       if ((buf->memory != V4L2_MEMORY_USERPTR) || (buf->baddr == 0))
+       if ((buf->memory != V4L2_MEMORY_USERPTR) || buf->baddr)
                return;
 
        if (!mem)