From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751149AbdKTMog convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Mon, 20 Nov 2017 07:44:36 -0500
Received: from mout.gmx.net ([212.227.15.19]:60094 "EHLO mout.gmx.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751061AbdKTMoe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 20 Nov 2017 07:44:34 -0500
Message-ID: <1511181834.11475.41.camel@gmx.de>
Subject: Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper
From: Mike Galbraith <efault@gmx.de>
To: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Mikulas Patocka <mpatocka@redhat.com>, linux-kernel@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>, linux-rt-users@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>
Date: Mon, 20 Nov 2017 13:43:54 +0100
In-Reply-To: <20171120105310.zsd6kotreig6nvik@linutronix.de>
References: <alpine.LRH.2.02.1711131245580.23280@file01.intranet.prod.int.rdu2.redhat.com>
         <20171117145744.t366d2ztxj2qqnco@linutronix.de>
         <1511030230.12841.42.camel@gmx.de>
         <20171120105310.zsd6kotreig6nvik@linutronix.de>
Content-Type: text/plain; charset="ISO-8859-15"
X-Mailer: Evolution 3.20.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8BIT
X-Provags-ID: V03:K0:q2Zpi/9A7rqp9PDxMWp0CSwHEVa2jt2MQCqvyAnqZeZXGq5FiqL
 aXMVYA99LDa6ZL75iNpNrtvrhADryNhzr7rFzJG0bLHeEYOfUDbib8ikUEnBOXEdQlKRTnO
 sQ+Y+xXNwH/P26XBeTMmfUgGVNx30QUmBkyp2pg6toHTR1dSNKZDgV4k8RhKHfQsv6VSJiP
 cOVmoEK3uTCZdmv9GjpxQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:iRfxl+x4MBY=:l5kKFFy+qE6xP4GCWNnukN
 f/+tAHv02K0XczSPRY7uDzoYG0RueiAYkyCXm4F5hfLGmJhIpnx7kiOXrLjv5xlHuvThluyYJ
 uIhhKR0+TrhjaMs8X/O2siTTiGLynVdfHReussWCOaNF4ZjUbGfp6bey49oKpNax6LaB9Zlvz
 tdgToNrPqR0lPxkCqafIoliwBRtpoY63iwqCs7UzOmOOMO7ZnM2IVj+wDn3wA3KBPGkC2C3p+
 5/ln4gZFT1wooulh0O9D8ks5eJLfEby93AozBau9d+oBCAMqe/Z2N4NIftiMQdvfRoSdgVQP7
 f83VtPM8tKX58083BUMICjQyJBQKvqhv8acutM6cmCBbCum80q7fulVZmNl95xxEURm0Afwf2
 /vspwyCQDGn9A2KY5wcXX0yrrz1TAatNyOXlDrq0OfbgKLIGWMR1MdWnOipQM+eIMjWcxiPwC
 A/UyD8iHFhOUuL++rth36k1LJOEbd4kIr1gwIMPuPiLK4FfopsxQLQsNCDExM5YQ0XOo3GESy
 yShzOc0/PaFXzGKqJ1192Y8upuHCarpwy4h6UyRGx2emFxcz8HICCmGJyyeI5UuBc0skGJ5+g
 NqrnrfiFS0KudrIx3f1varMVZOv28wUOcjgumrmvFNwHtTDZrYUzuOsXnzZlmQOZctIG/N1xY
 UtSLof+fn4JYlBoEoeTZff1P571rKqDVxSjWgIwTJh3RWcfkfQpIwnSUpztOGz/JejCaU/1rQ
 E6WYRoNpfnxgQmvf4eJGw4A/qYzQ5rDCVrogNfXUmbKCA4dQsQSt8Hr94KrYH3VPoQExTnSuo
 Y0oJupei078Pw4vNvnQ8bFoP4D0K9wIjskS23DuFeCLXbpHnP8=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2017-11-20 at 11:53 +0100, Sebastian Siewior wrote:
> 
> To your question whether or not delaying IO can cause any deadlocks is
> something that I can't answer and this something that would affect !RT,
> too. I tried to add lockdep to bit-spinlocks but this does not work
> because one context acquires the lock and another does the unlock. It
> has been explained to me that no deadlocks should happen as long as
> the IO is flushed before we block/wait on a lock.

That wasn't the question (guess I didn't formulate it well).  What I
was concerned about was the possibility that the situation that caused
me to add that __migrate_disabled() qualifier might arise anew, but
with different players.

At the time, I had to add that qualifier to prevent ABBA between the
owner of q->queue_lock, who was blocked by a lock ALREADY held by the
task trying to pull its plug, who then met the locked q->queue_lock.
 Ergo the less than perfect hack to only allow pulling the plug when
NOT YET holding a spinlock.  The problem was converted spinlocks (and
added RT locks).

	-Mike