From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992619AbdE0BSH (ORCPT ); Fri, 26 May 2017 21:18:07 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:33209 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1948767AbdEZVzW (ORCPT ); Fri, 26 May 2017 17:55:22 -0400 Date: Fri, 26 May 2017 14:55:18 -0700 From: Dmitry Torokhov To: "Luis R. Rodriguez" Cc: "Eric W. Biederman" , "Fuzzey, Martin" , Andy Lutomirski , "Michael Kerrisk (man-pages)" , Linux API , Peter Zijlstra , Greg KH , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , "Li, Yi" , atull@opensource.altera.com, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , Luca Coelho , Kalle Valo , Linus Torvalds , Kees Cook , AKASHI Takahiro , David Howells , Peter Jones , Hans de G oede , Alan Cox , "Ted Ts'o" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback Message-ID: <20170526215518.GB40877@dtor-ws> References: <20170524205658.GK8951@wotan.suse.de> <20170524214027.7775-1-mcgrof@kernel.org> <87fufr3mdy.fsf@xmission.com> <20170526194640.GS8951@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 26, 2017 at 02:32:31PM -0700, Luis R. Rodriguez wrote: > On Fri, May 26, 2017 at 2:26 PM, Dmitry Torokhov > wrote: > > On Fri, May 26, 2017 at 12:46 PM, Luis R. Rodriguez wrote: > >> On Fri, May 26, 2017 at 06:09:29AM -0500, Eric W. Biederman wrote: > >>> "Fuzzey, Martin" writes: > >>> >>>> Maybe SIGCHLD shouldn't interrupt firmware loading? > >>> > > >>> > I don't think there's a way of doing that without disabling all > >>> > signals (ie using the non interruptible wait variants). > >>> > It used to be that way (which is why I only ran into this after > >>> > updating from an ancient 3.16 kernel to a slightly less ancient 4.4) > >>> > But there are valid reasons for wanting to be able to interrupt > >>> > firmware loading (like being able to kill the userspace helper) > >>> > >>> Perhaps simply using a killable wait and not a fully interruptible > >>> wait would be better? > >> > >> What do you mean by a killable wait BTW? > > > > https://lwn.net/Articles/288056/ > > > > I think only interrupting firmware loading with fatal signals would > > make a lot of sense. > > > >> > >> ret = swait_event_interruptible_timeout() is being used right now. > > > > It looks like we are missing swait_event_killable*(), but I do not > > think it would be hard to add. > > What should we do for stable ? Is this a *stable* issue ? I think it is, as you have users complaining about behavior. I do not think we need to make their lives harder than needed by requiring handling signals. I do not see why we could not introduce wait_event_killable_timeout() and swait_event_killable_timeout() into -stables. Thanks. -- Dmitry