Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752339AbdF2QNi (ORCPT ); Thu, 29 Jun 2017 12:13:38 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:32927 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751804AbdF2QNa (ORCPT ); Thu, 29 Jun 2017 12:13:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170614222017.14653-1-mcgrof@kernel.org> <20170614222017.14653-3-mcgrof@kernel.org> <20170629125402.GH26046@kroah.com> <20170629133530.GA14747@kroah.com> From: Linus Torvalds Date: Thu, 29 Jun 2017 09:13:29 -0700 X-Google-Sender-Auth: X5QbBrx4JtCbA_YdD1ezflS7zwI Message-ID: Subject: Re: [PATCH 2/4] swait: add the missing killable swaits To: Thomas Gleixner Cc: Greg KH , "Luis R. Rodriguez" , mfuzzey@parkeon.com, "Eric W. Biederman" , Dmitry Torokhov , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , "Li, Yi" , atull@kernel.org, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , "Coelho, Luciano" , Kalle Valo , Andrew Lutomirski , Kees Cook , "AKASHI, Takahiro" , David Howells , Peter Jones , Hans de Goede , Alan Cox , "Theodore Ts'o" , Michael Kerrisk , Paul Gortmaker , Marcelo Tosatti , Matthew Wilcox , Linux API , linux-fsdevel , Linux Kernel Mailing List , "stable # 4 . 6" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 37 On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner wrote: > On Thu, 29 Jun 2017, Greg KH wrote: >> On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote: >> > >> > And who defined that it should not be used in real code? >> >> Linus did, in a different firmware thread. You have to _really_ know >> what you are doing to use this interface, and the firmware interface >> shouldn't be using it. So adding new apis just for firmware does not >> seem like a wise decision at this point in time. > > So it's not about code in general, it's about a particular piece of > code. Fair enough. Well, I'd actually say it the other way around: swait should not be used in general, only in _very_ particular pieces of code that actually explicitly need the odd swait semantics. swait uses special locking and has odd semantics that are not at all the same as the default wait queue ones. It should not be used without very strong reasons (and honestly, the only strong enough reason seems to be "RT"). The special locking means that swait doesn't do DEBUG_LOCK_ALLOC, but it also means that it doesn't even work in all contexts. So "swake_up()" does surprising things (only wake up one - that's what caused a firmware loading bug), and "swake_up_all()" has magic rules about interrupt disabling. The thing is simply a collection of small hacks and should NOT be used in general. I never want to see a driver use that code, for example. It was designed for RCU and RT, and it should damn well be limited to that. Linus