Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp116441iof; Sun, 5 Jun 2022 22:52:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcoXLZEDK/ijmftYUtPaHoDesr33jc1EWjC/OOld0SrerGzlnSacADuoS/9LTax9eoZ9AP X-Received: by 2002:a05:6a00:114e:b0:4c8:55f7:faad with SMTP id b14-20020a056a00114e00b004c855f7faadmr51384481pfm.86.1654494730447; Sun, 05 Jun 2022 22:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654494730; cv=none; d=google.com; s=arc-20160816; b=GBpPWe+4PgD2YqTpLchLxkgd6GwmIjneovYGXxV5N/GnS7dBNpotkKYLlzWsxb3iR6 BRKZHGbwkS0p48y9QANwIjg9PXVReq5oDqioZb34oJZPTP4JkFwhTKHAzUlzrYNaa8C4 h3kVybHSZpchfSKPDzWdNRe/eRxlbHDiAF72NpDDh+cY0S9nCYd3y9SBGQ6MM/u2hF7U BQvB0TMYsl2TDOW8HQ5KhA7Ae3PZWDdlEcPb5XYjXwwKbDrgcgSQj1yqtI0+9KYIDZIp +yLfLjxp0hyeEJzp0muBChHogTOZt8bilguJ8tdOSLGRSBkTMgZksGfnAIEQ29xb4UQ+ Ic7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=MDHxff61Dl5Upr0PRmHsYSxyyLmgrxP8vgPRdGpqA6U=; b=ELdiGslSn4XSltn6PO6eoPN3p9gRTzA9WkviPYMyt/QMlnN/iT7QwAlcukDDKFtVJt 6vtBpoDLVQL0U6ndZwytWpFLQ3EOWd9+JRiCQNAeuJ0i0v8i8GeOkN7k970/ukeWn+xt nXxdcdd/eA3czAPt4ZLfTW1rrPBROXfhS7astvG6zzK2KWlU3dJxs1zy6LA/7FL6e8QS OlT5YBsgMczADvzWnm+S/JEF9L9DujLRkK3OCCBuDmnqJn6aPQRiRlE9NMA4VFg29W3r t5pjXrE39eRv6V+ueec8BLC/p20HJHMgOJhB0kXl+BP68kHKW4reNfaU6+p3ZMeB9PW5 XOSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=keesDG7s; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id z22-20020aa78896000000b0051c29c6571bsi508424pfe.203.2022.06.05.22.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 22:52:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=keesDG7s; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5C8702A3BBF; Sun, 5 Jun 2022 21:40:56 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239234AbiFEM0Q (ORCPT + 99 others); Sun, 5 Jun 2022 08:26:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231252AbiFEM0O (ORCPT ); Sun, 5 Jun 2022 08:26:14 -0400 X-Greylist: delayed 415 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sun, 05 Jun 2022 05:26:13 PDT Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D7B544A0E for ; Sun, 5 Jun 2022 05:26:13 -0700 (PDT) Received: from [192.168.2.145] (109-252-138-163.dynamic.spd-mgts.ru [109.252.138.163]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 42BC666021F4; Sun, 5 Jun 2022 13:19:14 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1654431554; bh=twKaKpBVHMt3pJbT7iWckMFsSCOrXNFwcbzhziI8jIg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=keesDG7st6wjge+glyw1VIFV9gnuuHlFAge/By87O5r8bp4vQoda1j8U5unMuOYA1 1n03sE6jCBiyxmFFEz2tnFjWWg9DC/jtveaXjq1n1HaZbIL11Cpfj3tQQrsyQt6No1 ZjPXjNRUEpT0HJ3DlhDobi9WcUAk9mUXexuT4GIC7CYpRAE4LQLduXI/+oV3lgE00G tcBc6Wm5KriQ9BcXrZ3rKry+H3d5o5jCRdmRb793L0oJ5EGGZm1pJJb9Zj6Z1Kk3QO 8PBl3pDUSokjJEyiRbIXLFydl77Vl2eHIGV+h778T6SneznAeKzGsyw6GHN833dHvO JLVY78femTB4A== Message-ID: Date: Sun, 5 Jun 2022 15:19:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v1] kernel/reboot: Change registration order of legacy power-off handler Content-Language: en-US To: Michael Ellerman , "Rafael J . Wysocki" , Geert Uytterhoeven Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <20220524212118.425702-1-dmitry.osipenko@collabora.com> <8735gjq365.fsf@mpe.ellerman.id.au> From: Dmitry Osipenko In-Reply-To: <8735gjq365.fsf@mpe.ellerman.id.au> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, On 6/5/22 05:01, Michael Ellerman wrote: > Dmitry Osipenko writes: >> We're unconditionally registering sys-off handler for the legacy >> pm_power_off() callback, this causes problem for platforms that don't >> use power-off handlers at all and should be halted. Now reboot syscall >> assumes that there is a power-off handler installed and tries to power >> off system instead of halting it. >> >> To fix the trouble, move the handler's registration to the reboot syscall >> and check the pm_power_off() presence. > > I'm seeing a qemu virtual machine (ppce500) fail to power off using the > gpio-poweroff driver. I bisected it to this commit. > > I think the problem is that the machine is going via kernel_power_off(), > not sys_reboot(), and so legacy_pm_power_off() has not been registered. > > If I just put the core_initcall back then it works as before. Not sure > if that's a safe change in general though. Thank you very much for the testing and reporting the problem! I see now the two more cases that were missed previously: 1. There is the orderly_poweroff() used by some drivers. 2. PowerPC may invoke do_kernel_power_off() directly from xmon code. Could you please test this change: --- >8 --- diff --git a/kernel/reboot.c b/kernel/reboot.c index 3b19b123efec..0e4a3defcd94 100644 --- a/kernel/reboot.c +++ b/kernel/reboot.c @@ -320,6 +320,7 @@ static struct sys_off_handler platform_sys_off_handler; static struct sys_off_handler *alloc_sys_off_handler(int priority) { struct sys_off_handler *handler; + gfp_t flags; /* * Platforms like m68k can't allocate sys_off handler dynamically @@ -330,7 +331,12 @@ static struct sys_off_handler *alloc_sys_off_handler(int priority) if (handler->cb_data) return ERR_PTR(-EBUSY); } else { - handler = kzalloc(sizeof(*handler), GFP_KERNEL); + if (system_state > SYSTEM_RUNNING) + flags = GFP_ATOMIC; + else + flags = GFP_KERNEL; + + handler = kzalloc(sizeof(*handler), flags); if (!handler) return ERR_PTR(-ENOMEM); } @@ -615,7 +621,26 @@ static void do_kernel_power_off_prepare(void) */ void do_kernel_power_off(void) { + struct sys_off_handler *sys_off = NULL; + + /* + * Register sys-off handlers for legacy PM callback. This allows + * legacy PM callbacks temporary co-exist with the new sys-off API. + * + * TODO: Remove legacy handlers once all legacy PM users will be + * switched to the sys-off based APIs. + */ + if (pm_power_off) { + sys_off = register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, + SYS_OFF_PRIO_DEFAULT, + legacy_pm_power_off, NULL); + if (IS_ERR(sys_off)) + return; + } + atomic_notifier_call_chain(&power_off_handler_list, 0, NULL); + + unregister_sys_off_handler(sys_off); } /** @@ -626,7 +651,8 @@ void do_kernel_power_off(void) */ bool kernel_can_power_off(void) { - return !atomic_notifier_call_chain_is_empty(&power_off_handler_list); + return !atomic_notifier_call_chain_is_empty(&power_off_handler_list) || + pm_power_off; } EXPORT_SYMBOL_GPL(kernel_can_power_off); @@ -661,7 +687,6 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg) { struct pid_namespace *pid_ns = task_active_pid_ns(current); - struct sys_off_handler *sys_off = NULL; char buffer[256]; int ret = 0; @@ -686,21 +711,6 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, if (ret) return ret; - /* - * Register sys-off handlers for legacy PM callback. This allows - * legacy PM callbacks temporary co-exist with the new sys-off API. - * - * TODO: Remove legacy handlers once all legacy PM users will be - * switched to the sys-off based APIs. - */ - if (pm_power_off) { - sys_off = register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, - SYS_OFF_PRIO_DEFAULT, - legacy_pm_power_off, NULL); - if (IS_ERR(sys_off)) - return PTR_ERR(sys_off); - } - /* Instead of trying to make the power_off code look like * halt when pm_power_off is not set do it the easy way. */ @@ -758,7 +768,6 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, break; } mutex_unlock(&system_transition_mutex); - unregister_sys_off_handler(sys_off); return ret; }