Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752748AbbDPPdg (ORCPT <rfc822;w@1wt.eu>);
	Thu, 16 Apr 2015 11:33:36 -0400
Received: from www.linutronix.de ([62.245.132.108]:44490 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751434AbbDPPd0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 16 Apr 2015 11:33:26 -0400
Message-ID: <552FD643.8070408@linutronix.de>
Date: Thu, 16 Apr 2015 17:33:23 +0200
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>, Steven Rostedt <rostedt@goodmis.org>
CC: RT <linux-rt-users@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RT 3.18] ring-buffer: Mark irq_work as HARD_IRQ to prevent
 deadlocks
References: <552FC1FE.4020406@siemens.com>	<552FC6B1.1040000@linutronix.de>	<552FC72A.8060709@siemens.com> <20150416111041.66043164@gandalf.local.home> <552FD55F.8000105@siemens.com>
In-Reply-To: <552FD55F.8000105@siemens.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1076
Lines: 24

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/