Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751624AbdFIV3e (ORCPT ); Fri, 9 Jun 2017 17:29:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:51114 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538AbdFIV3b (ORCPT ); Fri, 9 Jun 2017 17:29:31 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFE3A23A23 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mcgrof@kernel.org MIME-Version: 1.0 In-Reply-To: References: <20170526194640.GS8951@wotan.suse.de> <20170526215518.GB40877@dtor-ws> <20170605202410.GQ8951@wotan.suse.de> <1496760796.5682.48.camel@linux.intel.com> <20170606164734.GB27288@wotan.suse.de> <20170606221151.ygoxqkwhhjsqw632@thunk.org> <20170607002237.GJ27288@wotan.suse.de> <20170607062515.GA23434@dtor-ws> From: "Luis R. Rodriguez" Date: Fri, 9 Jun 2017 14:29:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] firmware: fix sending -ERESTARTSYS due to signal on fallback To: Andy Lutomirski Cc: Dmitry Torokhov , "Theodore Ts'o" , Alan Cox , Linux FS Devel , Stephen Boyd , "Li, Yi" , Peter Zijlstra , Jonathan Corbet , "Eric W. Biederman" , "Michael Kerrisk (man-pages)" , Greg KH , "Fuzzey, Martin" , Linux API , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , 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 , "linux-kernel@vger.kernel.org" , Julia Lawall , "Luis R. Rodriguez" , atull@kernel.org 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: 1048 Lines: 23 On Thu, Jun 8, 2017 at 6:33 PM, Luis R. Rodriguez wrote: > On Thu, Jun 8, 2017 at 6:14 PM, Andy Lutomirski wrote: >> That's what I meant, but I said it unclearly. I meant that, if we're >> going to start allowing interruption, we would need to audit all the >> callers. Ugh. > > There are actually two audits worth evaluating if what we've concluded > is fair game: > > a) firmware sync calls on interruptible paths > b) use of swait / old interruptible waits on sysfs paths And as I noted in the other thread -- another possible issue could be any swait / interruptable wait on init or probe. Provided any child completes and the kernel code for wait handler does abort, that request would be terminated. This could for instance happen at bootup as modules load and any child from the loader terminates. We already have Coccinelle grammar to hunt for "though shall not request firmware on init or probe", such SmPL grammar could be in turn be repruposed to hunt for these types of conditions. Luis