linux-kernel - Re: mplayer v4l hangs in 2.6.25.2/4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080517111639.21a3e177@infradead.org>
Date:	Sat, 17 May 2008 11:16:39 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	"koos vriezen" <koos.vriezen@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: mplayer v4l hangs in 2.6.25.2/4

On Sat, 17 May 2008 18:54:06 +0200
"koos vriezen" <koos.vriezen@...il.com> wrote:

> Hi,
> 
> I'm using mplayer for tv watch quite some kernels but 2.6.25 makes
> mplayer unkillable. Last working kernel is 2.24.5 that I have tried.
> 
> This gets printed on the console
> 
> INFO: task mplayer:3465 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message. mplayer       D 0000000000000000     0  3465   3464
>  ffff810074333c68 0000000000200086 0000000000000000 00000000ffffffff
>  ffff81007a3889c0 ffff810074333c18 ffff810074333c98 ffffffff8064a800
>  ffffffff8064a800 ffffffff80646eb0 ffffffff8064a800 ffff8100757c1900
> Call Trace:
>  [<ffffffff8049b26f>] __mutex_lock_slowpath+0x68/0xa0
>  [<ffffffff802274aa>] enqueue_task_fair+0x72/0x9b
>  [<ffffffff8049b0ee>] mutex_lock+0x1a/0x1e
>  [<ffffffff802265aa>] enqueue_task+0x13/0x1e
>  [<ffffffff880b51ab>] :videobuf_core:videobuf_mmap_setup+0x1c/0x45
>  [<ffffffff8813dbbe>] :bttv:vidiocgmbuf+0x2c/0x99
>  [<ffffffff8810b91d>] :videodev:__video_do_ioctl+0xa1/0x2ad9
>  [<ffffffff802272d5>] set_next_entity+0x18/0x36
>  [<ffffffff8049aa70>] thread_return+0x3a/0xa4
>  [<ffffffff8810e622>] :videodev:video_ioctl2+0x17c/0x210
>  [<ffffffff80238c7b>] ptrace_stop+0xfc/0x140
>  [<ffffffff8023a705>] ptrace_notify+0x83/0xa6
>  [<ffffffff80289221>] vfs_ioctl+0x55/0x6b
>  [<ffffffff8028948a>] do_vfs_ioctl+0x253/0x264
>  [<ffffffff802894ec>] sys_ioctl+0x51/0x71
>  [<ffffffff8020bef8>] int_very_careful+0x35/0x3e
>  [<ffffffff8020be79>] tracesys+0xdc/0xe1
> 
> I've attached what might be usable wrt to this.
> 

Hi,

this smells like a deadlock (probably in v4l). Thankfully the kernel
has a lot of diagnostics for detecting deadlocks (you just found
that the  least invasive one caught the deadlock, but unfortunately it's
also the method that yields the least information).

Is it possible for you to enable lockdep (CONFIG_PROVE_LOCKING)?
With that on, the kernel will print nicely which locks are being waited
on, and if there's a deadlock, it'll print that too. Speaking of that,
since this looks like a mutex related issue, it's worth enabling
CONFIG_DEBUG_MUTEXES as well.... more debug checks in this area.
If you also enable CONFIG_FRAME_POINTER then the backtrace will get
better too (but it's not totally required, just easier for diagnostics)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/