From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Galbraith Subject: Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper Date: Tue, 21 Nov 2017 04:20:30 +0100 Message-ID: <1511234430.7672.26.camel@gmx.de> References: <20171117145744.t366d2ztxj2qqnco@linutronix.de> <1511030230.12841.42.camel@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8BIT Cc: Sebastian Siewior , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Steven Rostedt , linux-rt-users@vger.kernel.org To: Mikulas Patocka Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-rt-users.vger.kernel.org On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote: > > Is there some specific scenario where you need to call > blk_schedule_flush_plug from rt_spin_lock_fastlock? Excellent question.  What's the difference between not getting IO started because you meet a mutex with an rt_mutex under the hood, and not getting IO started because you meet a spinlock with an rt_mutex under the hood?  If just doing the mutex side puts this thing back to sleep, I'm happy. -Mike