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 S1751656AbdKUVVL convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Tue, 21 Nov 2017 16:21:11 -0500
Received: from mout.gmx.net ([212.227.17.20]:54265 "EHLO mout.gmx.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751611AbdKUVVK (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 21 Nov 2017 16:21:10 -0500
Message-ID: <1511299251.30074.72.camel@gmx.de>
Subject: Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper
From: Mike Galbraith <efault@gmx.de>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        Sebastian Siewior <bigeasy@linutronix.de>,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>, linux-rt-users@vger.kernel.org
Date: Tue, 21 Nov 2017 22:20:51 +0100
In-Reply-To: <alpine.LRH.2.02.1711211450410.10766@file01.intranet.prod.int.rdu2.redhat.com>
References: <alpine.LRH.2.02.1711131245580.23280@file01.intranet.prod.int.rdu2.redhat.com>
            <20171117145744.t366d2ztxj2qqnco@linutronix.de>
            <1511030230.12841.42.camel@gmx.de>
            <alpine.LRH.2.02.1711201607230.24006@file01.intranet.prod.int.rdu2.redhat.com>
         <1511234430.7672.26.camel@gmx.de>
           <alpine.DEB.2.20.1711210931460.1782@nanos>
          <1511255884.7672.49.camel@gmx.de>
          <alpine.LRH.2.02.1711211107550.12859@file01.intranet.prod.int.rdu2.redhat.com>
         <1511285619.30074.13.camel@gmx.de>
         <alpine.LRH.2.02.1711211450410.10766@file01.intranet.prod.int.rdu2.redhat.com>
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:IRTM/HSwhq8xeSiDVv/jkaS/mxZmYalMKuD2UraqhjPwahN7SwN
 T13IiInjOoBbpsL1YNh7lBtlVEeIWIJSyPpOg8q1U7R98c5GVsYBrobb0o/dFUoyzIplNrc
 8YtxSNet+6mN29qPM9wiiLK5m4WjSbu3RWnMKDuYttTcAVQodNav4Kqv6/a1hPZCTaWvtsI
 wSy/BnlCnf6RwFYVoAYMw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:cb9caPuhGdM=:kc9xuNOausiMfBWGMc9GVE
 rkhnWUPdyowKY7U31iKPMlWwnZMrQhB/z3j4VLZKNklVLpuhEcDmMAzyjwQL7F1mZxbmo0Mgo
 SNfeLS+vNU+W5D5Ooof22ybkTCVBCqYZlZS8waP+/pL2NQ79DHb/oGK5cg8p1OCEmoDb0zcBj
 SlmyI53Ls5hLU4naIdEgncqJfyqZgJf42mZR0U8pS84qS62+yIjWLK4wnOlzfS8dTBbFBafo5
 VoQvSi2HzViBQEDZaJR6EOHNORN26k5aLs2u2xuJKQWGnm+WBE1JZNar96xEwWe0Qi/PyxlVx
 ViWnz2tbWTOrQWj8gg66/7kzKoPcIENI6kd9/Yq0vXAUmV9yeixnSR3YbNtD3FDlqHBaYFOm3
 tRUuBxRxl5LnU1Mdtsv8RYJrvbNqwmVJbpHY64xNVlw/I0XF8SYuBEXhVGIz6CiaPhoKGhmma
 o7l3FdX/Qa3zZVzUHDhkk5wFzvPfs7CDct6MnHVQNpabY1D2aW2e3v+tyC6r/p1kLjktPCJMW
 W7VlatJ1kUpeQUyyoIkDMeRwGOSoznGVjAx4KFLhHd48gKKgFsad5Gpg1244BiYfgo71s1Thd
 arreun8xyTulBS8GjwuuUR8QjmxFQNn3PUKFNlOXmYOysPElWhSdHay5pz4ekc2d7rxVrxnFA
 wtuPBYbcpx0answgTtjS/8JtBI6qJ5NIhIp34HKOjNyDhMbnQxaOQveNTZdEY9J0KpysaUiI3
 RVJLubnjtJt+oWMebCUDj4tpKvuemkGm1MfdKALAr1g/s9I6eHaSTWqCw4K1snvScJdbOn8Am
 nSU5Kia2SswgtdMbLrtgDTjA19sbVOMDQFn7zk9Ljzh4/MYC2Q=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2017-11-21 at 14:56 -0500, Mikulas Patocka wrote:
> 
> If we don't have any reason why it is needed to unplug block requests when 
> a spinlock is taken - so let's not do this.

That's perfectly fine.  I guess I shouldn't have even mentioned having
encountered unplug at mutex being insufficient.

	-Mike