linux-kernel - [2.6.33.7-rt, epoll] kerneloops with FFADO on RT kernel

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>] [day] [month] [year] [list]

Message-ID: <20101207084626.76b386cb@stein>
Date:	Tue, 7 Dec 2010 08:46:26 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Knoth <adi@...omp.erfurt.thur.de>
Cc:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: [2.6.33.7-rt, epoll] kerneloops with FFADO on RT kernel

On Dec 06 Adrian Knoth wrote at linux1394-devel:
> I just noticed there is a kerneloops when using FFADO on 2.6.33.7-rt:
> 
> Kernel failure message 13:
> BUG: sleeping function called from invalid context at kernel/rtmutex.c:707
> pcnt: 1 0 in_atomic(): 1, irqs_disabled(): 0, pid: 10, name: sirq-tasklet/0
> Pid: 10, comm: sirq-tasklet/0 Not tainted 2.6.33.7-rt29rt #3
> Call Trace:
>  [<c1025318>] __might_sleep+0xcc/0xd4
>  [<c10593a5>] T.503+0x26/0x5f
>  [<c12365f2>] rt_spin_lock+0x8/0xa
>  [<c10d8b9a>] T.543+0x1e/0xad
>  [<c10d89b3>] ? ep_poll_wakeup_proc+0x0/0x1a
>  [<c102bc6f>] ? try_to_wake_up+0x374/0x388
>  [<c10d8c99>] ep_poll_safewake+0x28/0x4b
>  [<c10d91b4>] ep_poll_callback+0x9c/0xa6
>  [<c1022502>] __wake_up_common+0x34/0x5c
>  [<c1029cec>] __wake_up+0x26/0x34
>  [<f813ffdc>] queue_event+0x66/0x6f [firewire_core]
>  [<f8140c23>] handle_request+0x11d/0x157 [firewire_core]
>  [<f8144302>] fw_core_handle_request+0x32b/0x395 [firewire_core]
[...]
> I have plenty of those, one per second, but I'm not sure if there's
> really something wrong or if this "bug" is introduced by the RT
> patchset. FFADO works fine, and 2.6.33 is also pretty old wrt Juju, so
> this might all be noise.

There were issues with epoll in the mainline kernel before, but I
don't remember which kernels were affected.  But it could also be an
-rt specific problem.

We are definitely entitled to use wake_up_interruptible() in atomic
context (here: tasklet context), i.e. it is not a firewire bug.
-- 
Stefan Richter
-=====-==-=- ==-- --===
http://arcgraph.de/sr/
--
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/