Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752917AbdF2RlO (ORCPT ); Thu, 29 Jun 2017 13:41:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:38005 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751936AbdF2RlH (ORCPT ); Thu, 29 Jun 2017 13:41:07 -0400 Date: Thu, 29 Jun 2017 10:40:46 -0700 From: Davidlohr Bueso To: Linus Torvalds Cc: Thomas Gleixner , 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" Subject: Re: [PATCH 2/4] swait: add the missing killable swaits Message-ID: <20170629174046.GC3954@linux-80c1.suse> References: <20170614222017.14653-1-mcgrof@kernel.org> <20170614222017.14653-3-mcgrof@kernel.org> <20170629125402.GH26046@kroah.com> <20170629133530.GA14747@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 930 Lines: 25 On Thu, 29 Jun 2017, Linus Torvalds wrote: >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. For all the above, what do you think of my 'sswait' proposal? Thanks, Davidlohr