From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbcGXVsw (ORCPT ); Sun, 24 Jul 2016 17:48:52 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:58351 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752398AbcGXVst convert rfc822-to-8bit (ORCPT ); Sun, 24 Jul 2016 17:48:49 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Benjamin Herrenschmidt Cc: "linux-kernel\@vger.kernel.org" , Joel Stanley , Jeremy Kerr , Greg KH References: <1469307112.8568.224.camel@kernel.crashing.org> <87bn1nlibx.fsf@x220.int.ebiederm.org> <1469366126.8568.258.camel@kernel.crashing.org> Date: Sun, 24 Jul 2016 16:35:43 -0500 In-Reply-To: <1469366126.8568.258.camel@kernel.crashing.org> (Benjamin Herrenschmidt's message of "Sun, 24 Jul 2016 23:15:26 +1000") Message-ID: <87invuhg7k.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1bRRGL-0008Qt-2s;;;mid=<87invuhg7k.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19IsheVl+vhof19EoZCcheyLbo6pD0B6/Y= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% * [score: 0.1081] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Benjamin Herrenschmidt X-Spam-Relay-Country: X-Spam-Timing: total 5856 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 9 (0.2%), b_tie_ro: 5 (0.1%), parse: 1.45 (0.0%), extract_message_metadata: 14 (0.2%), get_uri_detail_list: 1.19 (0.0%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.33 (0.0%), tests_pri_-900: 1.06 (0.0%), tests_pri_-400: 21 (0.4%), check_bayes: 19 (0.3%), b_tokenize: 5.0 (0.1%), b_tok_get_all: 6 (0.1%), b_comp_prob: 2.6 (0.0%), b_tok_touch_all: 2.7 (0.0%), b_finish: 0.88 (0.0%), tests_pri_0: 309 (5.3%), check_dkim_signature: 0.65 (0.0%), check_dkim_adsp: 4.9 (0.1%), tests_pri_500: 5489 (93.7%), poll_dns_idle: 5468 (93.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: kexec: device shutdown vs. remove X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Benjamin Herrenschmidt writes: > On Sun, 2016-07-24 at 00:24 -0500, Eric W. Biederman wrote: >> If you are willing to do the work to merge shutdown into remove and >> simplify the drivers, perform the testing and the other state I am in >> favor of the change.  I think we have had enough time to see if have two >> methods was maintainable for the driver authors. > > Well, remove is going away in some drivers at least... > > Also shutdown() has two different meaning between kexec and actual > machine shutdown... > > Should we create a new one instead ? Something like quiesce() ? If > absent, look for remove(), if absent too, look for shutdown() ... > > Or we continue doing shutdown() for now with a fallback to remove() if > shutdown is NULL (this is what I've been toying with internally). A shutdown method that doesn't work for kexec is a poorly tested buggy implementation of shutdown. I don't driver authors for the confusion but it remains true that shutdown has always been called in the kexec path. So if your shutdown method does not work for kexec it is buggy (by definition). Eric