From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751319AbdKUJS0 convert rfc822-to-8bit (ORCPT ); Tue, 21 Nov 2017 04:18:26 -0500 Received: from mout.gmx.net ([212.227.15.15]:54947 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbdKUJSW (ORCPT ); Tue, 21 Nov 2017 04:18:22 -0500 Message-ID: <1511255884.7672.49.camel@gmx.de> Subject: Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper From: Mike Galbraith To: Thomas Gleixner Cc: Mikulas Patocka , Sebastian Siewior , linux-kernel@vger.kernel.org, Ingo Molnar , Steven Rostedt , linux-rt-users@vger.kernel.org Date: Tue, 21 Nov 2017 10:18:04 +0100 In-Reply-To: References: <20171117145744.t366d2ztxj2qqnco@linutronix.de> <1511030230.12841.42.camel@gmx.de> <1511234430.7672.26.camel@gmx.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:jS6L7GiP8TOGF4/DrBILc9CgJSqYpgcbhTNv0b24KUzvwN+7o03 anfvjzgwAWiCSr1akCHB91wolhrBvx9v/XYmsvrMxx5C8Mdf7fkefYKY/pvnVOw47qhxqI5 QETGPLXUlW1cpf+Vo8fCQ9lc/coX9khd1FkbYL8DrrDMazAMX1FjjWpj/KZ6lPhB7fcjBjW KlTPgVATlGUg9Jlmg0Rtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:EFvYKLm9uFg=:NRjkvA1wa5ct1rekE3HvnU M3XEIwiVbOkZtGdyTPwj5QxGLO+gddtMdV32H8WHQwBCIAcWTfoN5qQTMLwIwZcn6cYzNMyc0 SeJkAIXTKD0aF3W3Chq9m+j7S8PlUSvfPHBGiGzCm5XYthpOUU1DJ/HC6Z2m0r2PcRj7w7UhR xVuCNq8hlVTiAB4K11uEld3SLSnremkagFbQIw39im7B4l3u0e+ixce8fAsKGjIEHbFCM3o9G 1qb0gF5I3a5tIR+2x4Q65p2O/3Tc/CB1No3FjWJ9l3Bprjx8TflHTgKIkbB5YOWQWAjnGpPo9 vJQUTx4rIshO3F0OVCd1uaxpVO8f0n+R3obVzgGEIoL8dmd38oLSFDrW7Jc6nfMUAZSJpIPDh MHP6IHxS1tRK8JHpu4Lp1znT34uzsSyPJ18KriBcJja69smjozsc5HkmjXqu1gg5neMzsY7p1 1TXE3IyPAJi+GlA0xCF5CMa1f8wISz89Gx5ba08l8R/5f+70j+TtG5vt7FFJYZlWkhI7qCyg5 taUBFiO78Vm6sQpFa46jxs5r5yLgQAGqt+82GIW1LpUy9bg9C1yFJie28Akfd63fEmuXg11nw 6A5miEAVKu04P4rdxeunKeGMOg/sR4LJmJvGE/Ys2JctgSCE7AVb1NBcg8ujFZBV/cpaxhEuS TTYEyg+ygj2S32+XGK9DMMVlQqUuwc46uCL7wNkAaYrEbc0VmTXdR9F4tjdLzG7AvhWG24Pgt 2fWDY62eFe3/+bAaI59TWbHys2qfgE3WWX9jSO7SxGhFOPTZmfLgjKxPJOZDkWPiWxsGzcala UOS68iqPXMQbgKZlu20cZWOuB47suyX9Y5e2hKhdyyJrUM12Uc= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-11-21 at 09:37 +0100, Thomas Gleixner wrote: > On Tue, 21 Nov 2017, Mike Galbraith wrote: > > 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. > > Think about it from the mainline POV. > > The spinlock cannot ever go to schedule and therefore cannot create a > situation which requires an unplug. The RT substitution of the spinlock > with a rtmutex based sleeping spinlock should not change that at all. > > A regular mutex/rwsem etc. can and will unplug when the lock is contended > and the caller blocks. The RT conversion of these locks to rtmutex based > variants creates the problem: Unplug cannot be called when the task has > pi_blocked_on set because the unplug path might content on yet another > lock. So unplugging in the slow path before setting pi_blocked_on is the > right thing to do. Sure.  What alarms me about IO deadlocks reappearing after all this time is that at the time I met them, I needed every last bit of that patchlet I showed to kill them, whether that should have been the case or not.  'course that tree contained roughly a zillion patches.. Whatever, time will tell if I'm properly alarmed, or merely paranoid :) -Mike