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>