Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4082561ioo; Wed, 25 May 2022 14:36:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPAj1Ly4BfqeFNC1C4W6SCAx+EIAi0pRckzhWPm3RDSb9bbggmIV5YeWH25QDmknnvx37Q X-Received: by 2002:a05:6a00:238f:b0:4f7:78b1:2f6b with SMTP id f15-20020a056a00238f00b004f778b12f6bmr35681526pfc.17.1653514600576; Wed, 25 May 2022 14:36:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653514600; cv=none; d=google.com; s=arc-20160816; b=emwwD5frdiqLs6nilxYui/OZ8soU/Vv22UWeD+I/zK5x3GNwdCEpnrcOdEo6o8dJPt fC7tq176KkAuCRTyZiWRs4ZbySAeLBkfmeLra1Nrt9Hs/vvKneoZygjAOZQSTunsMEEL RM3SXy71/KKziRfUFRxIHKeLHt1uPGFD0iggldvSYBsCOpqqZhxWQUPYkIEuPTrd2Gp9 xa4Ok6dbDE+BkA9miLE6X2GKD0wWVK0PdekMFZt4ZUDeghf5tnGWMh9yEVF4m5Fpx89w Vmz9l6eTWmYsicB+dAp0fuaYVuj2nfYl72ser/Po33zbwUQRTAqPFUP/3ubNdlplSHek 0IAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=XbTQQ3fFsREZ3tUhy2vBlOH2mWBOf5JDmMrH0eHv+2E=; b=aL1J/arsX1kHg9YzmvEp9ywoT2Oiy9i61n9b7hIdybZUpaSbVw0Y9pCrVEdRsdXF8p nN6csV+POjvyoCv9mFp3WyaMQsgGPXoOJmnB7s9aPaIMzGhHEbXOwsANBHbd9rH2Htt2 wuwdVNUmLulOtarjMd6R/KG5d/aY5yHvzxUIB4wxNXcEzsYAgTsbG5dAy4iRBcvd09UQ eCD4Dr0+1qbh4v4RsWw+XZgT+DlKTJL5mWRJ94datW78NqjnsHkg6stLb33yaVGOAMEy QMeq6nLt8juB0YuwwDFMczh8npuIUm78I86VN29J83ILXg82lyBM3WusNfVA8W37lQAG /H/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o11-20020a17090a55cb00b001d97ad1c408si3395368pjm.147.2022.05.25.14.36.29; Wed, 25 May 2022 14:36:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243624AbiEYM5J (ORCPT + 99 others); Wed, 25 May 2022 08:57:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229831AbiEYM5H (ORCPT ); Wed, 25 May 2022 08:57:07 -0400 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7C1BA0051 for ; Wed, 25 May 2022 05:57:06 -0700 (PDT) Received: by mail-yb1-f178.google.com with SMTP id g72so8071960ybf.0 for ; Wed, 25 May 2022 05:57:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XbTQQ3fFsREZ3tUhy2vBlOH2mWBOf5JDmMrH0eHv+2E=; b=d4N0E7Xfbb7foV+cJmtF6eHJT1qjiLSSMK1qK8yL31OosmRjePjL/M9gOulWmnwfGB pcR5iMo0ARzmSTA+C1zaVxN+w9Et1TN/3KBG5I39LLQcaQXwXZoMmr9VDfGk19sML6Oe 1Sv2T4tBHR0SUOA2ThXVbNtYPcWD6NnuiTDDVU7KZGGxoUvZymAv/TwzCYeCviHGAzJW GbPlgE6QM2aWCz9I525/ufPVZh/Rep5FTiuv2flyDyiWXrhCkS305/qy7WrvYZ/lVcwo o3lqx33n6r0B/pPaCYtHMmbw77GwzNIRC8bs0RiLwVUrDN2ikCgUvKXR2OPp8bNpM2D7 n0NA== X-Gm-Message-State: AOAM5314/vBxgSh17DirGkz4zpoHrGyquxCVHemnqop8K67HO6y+SOIi qBdSnBITBkAcJClbPe0OZIIDwqYlbiEMUHOPbdU= X-Received: by 2002:a25:6b50:0:b0:64f:4b33:664 with SMTP id o16-20020a256b50000000b0064f4b330664mr28570255ybm.153.1653483426127; Wed, 25 May 2022 05:57:06 -0700 (PDT) MIME-Version: 1.0 References: <20220524212118.425702-1-dmitry.osipenko@collabora.com> In-Reply-To: <20220524212118.425702-1-dmitry.osipenko@collabora.com> From: "Rafael J. Wysocki" Date: Wed, 25 May 2022 14:56:55 +0200 Message-ID: Subject: Re: [PATCH v1] kernel/reboot: Change registration order of legacy power-off handler To: Dmitry Osipenko Cc: "Rafael J . Wysocki" , Geert Uytterhoeven , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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 On Tue, May 24, 2022 at 11:23 PM Dmitry Osipenko wrote: > > 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. > > Fixes: 0e2110d2e910 ("kernel/reboot: Add kernel_can_power_off()") > Reported-by: Geert Uytterhoeven > Tested-by: Geert Uytterhoeven > Signed-off-by: Dmitry Osipenko > --- > kernel/reboot.c | 33 +++++++++++++++++---------------- > 1 file changed, 17 insertions(+), 16 deletions(-) > > diff --git a/kernel/reboot.c b/kernel/reboot.c > index 0bdc64ecf4f6..a091145ee710 100644 > --- a/kernel/reboot.c > +++ b/kernel/reboot.c > @@ -569,22 +569,6 @@ static int legacy_pm_power_off(struct sys_off_data *data) > return NOTIFY_DONE; > } > > -/* > - * Register sys-off handlers for legacy PM callbacks. This allows legacy > - * PM callbacks 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. > - */ > -static int __init legacy_pm_init(void) > -{ > - register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, SYS_OFF_PRIO_DEFAULT, > - legacy_pm_power_off, NULL); > - > - return 0; > -} > -core_initcall(legacy_pm_init); > - > static void do_kernel_power_off_prepare(void) > { > blocking_notifier_call_chain(&power_off_prep_handler_list, 0, NULL); > @@ -646,6 +630,7 @@ 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; > > @@ -670,6 +655,21 @@ 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. > */ > @@ -727,6 +727,7 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, > break; > } > mutex_unlock(&system_transition_mutex); > + unregister_sys_off_handler(sys_off); > return ret; > } > > -- Applied, thanks!