From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933339AbdEZTrD (ORCPT ); Fri, 26 May 2017 15:47:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:41627 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754444AbdEZTqn (ORCPT ); Fri, 26 May 2017 15:46:43 -0400 Date: Fri, 26 May 2017 21:46:40 +0200 From: "Luis R. Rodriguez" To: "Eric W. Biederman" Cc: "Fuzzey, Martin" , Andy Lutomirski , "Luis R. Rodriguez" , "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: <20170526194640.GS8951@wotan.suse.de> References: <20170524205658.GK8951@wotan.suse.de> <20170524214027.7775-1-mcgrof@kernel.org> <87fufr3mdy.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fufr3mdy.fsf@xmission.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? ret = swait_event_interruptible_timeout() is being used right now. The problem is we have: if (ret != 0 && fw_st->status == FW_STATUS_ABORTED) return -ENOENT; if (!ret) return -ETIMEDOUT; return ret < 0 ? ret : 0; The (!ret) return -ETIMEDOUT ensures that if there was no time left then we know we ran out of time. The ret < 0 ? ret makes sure we send any errors swait_event_interruptible_timeout() sent. But the caller of this code has: if (fw_state_is_aborted(&buf->fw_st)) retval = -EAGAIN; else if (buf->is_paged_buf && !buf->data) retval = -ENOMEM; And this retval is used. so we mask all errors with -EAGAIN. So Martin is asking us to let us send -ERESTARTSYS back down to drivers. These potentially could send back down to probe, and so finit_module() could get this. Another use case is a custom syfs knob which triggers a request_firmware(), in such case this is a simple write(), but Anroid is configured to retry if -ERESTARTSYS so I gather it will *retry* writing again to this file if -ERESTARTSYS was sent and therefore triggering another firmware request. > It sounds like the code really is not prepared for an truly > interruptible wait here. Can you clarify what you mean? Luis