[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <552FD643.8070408@linutronix.de>
Date: Thu, 16 Apr 2015 17:33:23 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Jan Kiszka <jan.kiszka@...mens.com>,
Steven Rostedt <rostedt@...dmis.org>
CC: RT <linux-rt-users@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RT 3.18] ring-buffer: Mark irq_work as HARD_IRQ to prevent
deadlocks
On 04/16/2015 05:29 PM, Jan Kiszka wrote:
> My patch is definitely not OK. It causes
>
> [ 380.372579] BUG: scheduling while atomic: trace-cmd/2149/0x00010004
> ...
> [ 380.372604] Call Trace:
> [ 380.372610] <IRQ> [<ffffffff81607694>] dump_stack+0x50/0x9f
> [ 380.372613] [<ffffffff8160413c>] __schedule_bug+0x59/0x69
> [ 380.372615] [<ffffffff8160a1d5>] __schedule+0x675/0x800
> [ 380.372617] [<ffffffff8160a394>] schedule+0x34/0xa0
> [ 380.372619] [<ffffffff8160bf7d>] rt_spin_lock_slowlock+0xcd/0x290
> [ 380.372621] [<ffffffff8160d8b5>] rt_spin_lock+0x25/0x30
> [ 380.372623] [<ffffffff8108fe39>] __wake_up+0x29/0x60
right. you must not take any sleeping locks in the hardirq context :)
This works for the no-hz-work thingy. It grabs raw locks and may cancel
one hrtimer which is marked irqsafe.
Sebastian
--
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/
Powered by blists - more mailing lists