Message ID | feeb1a89-59bd-4fd6-81a5-1d828f95b0f0@ancud.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp1075020vqo; Wed, 8 Nov 2023 09:36:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IGmTIgecurC7A7vVpN8LHk9HlSf3oE+E178uU1JKL1P5Hi23tjOyHKuG0fZL0qFYCtzwasE X-Received: by 2002:a05:6358:78a:b0:16b:63ba:4b68 with SMTP id n10-20020a056358078a00b0016b63ba4b68mr2231197rwj.15.1699464966365; Wed, 08 Nov 2023 09:36:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699464966; cv=none; d=google.com; s=arc-20160816; b=ryMHFKhd9T1bdjMVBVgWWighDsO0sAoybkPykd8HBpqlAFya6ijAZPF9zw1ALnEXjz gkYG9ADrmN8xhJljR6OI18FfRYo7N52vt/zpWn5Py9RiYkwYgoX51AvzPqlBM5dsifhu YPhIYpKCNxOM4kmQeP7H1g5kW3RTjwF7K/o+qzbJxvcmKdTuOOAzi0MXFucnMs0kVh+a dGGb/lrk7YDRpzxtVO8KDqGrpMq3NDMO+OglnU0OGHIMEMquk5yH95I/PkW6JIYaNkc/ mPFkMmr+pBPmDk5/lyULcN7d2mHHBgAlRdo7JBz1W9d9A1O6SgEfDo4rdepOpFWT4cih vg5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language:cc:to :subject:from:user-agent:mime-version:date:message-id; bh=ujNNT5725UKE3wj2h6PZLbAX5vEYuakHgLqXmQRl1Kw=; fh=nuSLYOO8XGHp9cJTtgqEstr3iOvsLDCfFDbytoUZBfw=; b=AEMiMkXobWSSEEyCN7si4zlLee2s9J/vgdAq89jx7C5Rkei1vYMW9+vgtnMDOVRuF5 8R5YlV1ByvjLSswbvA050nDRFk5JuRGecyzfnibXY0QPujPD38PetoDfEYBN3Su4mQyI dRr248hzC+A2WdGLF4fdpuOMQCtpg2dc3VbftAuIsnn8Ag7xBoPgLO6PWXf4+jJUy9lW WKFEn30aCQ5EZZpViF1d5fz8At08apqfi5vSfcnwVd74oTf/sv57h6qdhLVDOG+fMXXQ u27q4yoxQk7y4cevX43lNxKN+m65CAHTUuwgps4Fl7x0PCGWNaRHRyVscqy56YQGr7Lm lZzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id s64-20020a637743000000b005bdd7eaab1fsi2220153pgc.526.2023.11.08.09.36.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 09:36:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 06C4C81373F1; Wed, 8 Nov 2023 09:35:51 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232099AbjKHRfj (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Wed, 8 Nov 2023 12:35:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230118AbjKHRfh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Nov 2023 12:35:37 -0500 X-Greylist: delayed 447 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 08 Nov 2023 09:35:30 PST Received: from relay163.nicmail.ru (relay163.nicmail.ru [91.189.117.7]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CA3E1FC8; Wed, 8 Nov 2023 09:35:30 -0800 (PST) Received: from [10.28.136.255] (port=50502 helo=[192.168.95.111]) by relay.hosting.mail.nic.ru with esmtp (Exim 5.55) (envelope-from <kiryushin@ancud.ru>) id 1r0mLO-0006Tf-Br; Wed, 08 Nov 2023 20:27:59 +0300 Received: from [87.245.155.195] (account kiryushin@ancud.ru HELO [192.168.95.111]) by incarp1105.mail.hosting.nic.ru (Exim 5.55) with id 1r0mLO-0000zR-1w; Wed, 08 Nov 2023 20:27:58 +0300 Message-ID: <feeb1a89-59bd-4fd6-81a5-1d828f95b0f0@ancud.ru> Date: Wed, 8 Nov 2023 20:27:57 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Nikita Kiryushin <kiryushin@ancud.ru> Subject: [PATCH] power: reset: msm: Process register_restart_handler() error To: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Sebastian Reichel <sre@kernel.org>, Stephen Boyd <sboyd@codeaurora.org>, Pramod Gurav <pramod.gurav@smartplayin.com>, Guenter Roeck <linux@roeck-us.net>, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MS-Exchange-Organization-SCL: -1 Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 08 Nov 2023 09:35:51 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782018176823574606 X-GMAIL-MSGID: 1782018176823574606 |
Series |
power: reset: msm: Process register_restart_handler() error
|
|
Commit Message
Nikita Kiryushin
Nov. 8, 2023, 5:27 p.m. UTC
If registering restart handler fails for msm-restart result is not checked.
It may be irrelevant now (as stated in comment to register_restart_handler,
the function currently always returns zero), but if the behavior changes
in the future, an error at registration of handler will be silently skipped.
Add return error code and print error message too debug log in case of
non-zero result of register_restart_handler.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 18a702e0de98 ("power: reset: use restart_notifier mechanism for
msm-poweroff")
Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
---
drivers/power/reset/msm-poweroff.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
Hi, On Wed, Nov 08, 2023 at 08:27:57PM +0300, Nikita Kiryushin wrote: > If registering restart handler fails for msm-restart result is not checked. > It may be irrelevant now (as stated in comment to register_restart_handler, > the function currently always returns zero), but if the behavior changes > in the future, an error at registration of handler will be silently skipped. > > Add return error code and print error message too debug log in case of > non-zero result of register_restart_handler. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 18a702e0de98 ("power: reset: use restart_notifier mechanism for > msm-poweroff") > > Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru> > --- If register_restart_handler fails, it might actually be a good idea to continue and at least have a poweroff handler :) > drivers/power/reset/msm-poweroff.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/reset/msm-poweroff.c > b/drivers/power/reset/msm-poweroff.c > index b9a401bd280b..5877a1ba2778 100644 > --- a/drivers/power/reset/msm-poweroff.c > +++ b/drivers/power/reset/msm-poweroff.c > @@ -35,11 +35,16 @@ static void do_msm_poweroff(void) > static int msm_restart_probe(struct platform_device *pdev) > { > + int ret = -EINVAL; no need to initialize, it's overwritten before being used. > msm_ps_hold = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(msm_ps_hold)) > return PTR_ERR(msm_ps_hold); > - register_restart_handler(&restart_nb); > + ret = register_restart_handler(&restart_nb); > + if (ret) { > + dev_err(&pdev->dev, "unable to register restart handler, %d\n", ret); > + return ret; There is dev_err_probe() for this, but as mentioned above it's more sensible not to fail here. -- Sebastian > + } > pm_power_off = do_msm_poweroff; > -- 2.34.1 >
On 11/8/2023 10:57 PM, Nikita Kiryushin wrote: > If registering restart handler fails for msm-restart result is not checked. > It may be irrelevant now (as stated in comment to register_restart_handler, > the function currently always returns zero), but if the behavior changes > in the future, an error at registration of handler will be silently > skipped. > > Add return error code and print error message too debug log in case of > non-zero result of register_restart_handler. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. > > Fixes: 18a702e0de98 ("power: reset: use restart_notifier mechanism for > msm-poweroff") > > Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru> > --- > drivers/power/reset/msm-poweroff.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/reset/msm-poweroff.c > b/drivers/power/reset/msm-poweroff.c > index b9a401bd280b..5877a1ba2778 100644 > --- a/drivers/power/reset/msm-poweroff.c > +++ b/drivers/power/reset/msm-poweroff.c > @@ -35,11 +35,16 @@ static void do_msm_poweroff(void) > static int msm_restart_probe(struct platform_device *pdev) > { > + int ret = -EINVAL; This does not add up anything., no need to initialize. -Mukesh > msm_ps_hold = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(msm_ps_hold)) > return PTR_ERR(msm_ps_hold); > - register_restart_handler(&restart_nb); > + ret = register_restart_handler(&restart_nb); > + if (ret) { > + dev_err(&pdev->dev, "unable to register restart handler, %d\n", > ret); > + return ret; > + } > pm_power_off = do_msm_poweroff; > -- 2.34.1 >
On 12/16/23 00:15, Mukesh Ojha wrote: > > > On 11/8/2023 10:57 PM, Nikita Kiryushin wrote: >> If registering restart handler fails for msm-restart result is not checked. >> It may be irrelevant now (as stated in comment to register_restart_handler, >> the function currently always returns zero), but if the behavior changes >> in the future, an error at registration of handler will be silently skipped. >> >> Add return error code and print error message too debug log in case of >> non-zero result of register_restart_handler. >> >> Found by Linux Verification Center (linuxtesting.org) with SVACE. >> >> Fixes: 18a702e0de98 ("power: reset: use restart_notifier mechanism for msm-poweroff") >> >> Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru> >> --- >> drivers/power/reset/msm-poweroff.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/power/reset/msm-poweroff.c b/drivers/power/reset/msm-poweroff.c >> index b9a401bd280b..5877a1ba2778 100644 >> --- a/drivers/power/reset/msm-poweroff.c >> +++ b/drivers/power/reset/msm-poweroff.c >> @@ -35,11 +35,16 @@ static void do_msm_poweroff(void) >> static int msm_restart_probe(struct platform_device *pdev) >> { >> + int ret = -EINVAL; > > This does not add up anything., no need to initialize. > > -Mukesh > > >> msm_ps_hold = devm_platform_ioremap_resource(pdev, 0); >> if (IS_ERR(msm_ps_hold)) >> return PTR_ERR(msm_ps_hold); >> - register_restart_handler(&restart_nb); >> + ret = register_restart_handler(&restart_nb); FWIW, checking this return value really do anything good either. The only possible return value is -EEXIST, which would be returned if the restart handler was already registered, and that can not really happen. On top of that, _if_ that happened, the notifier core would dump a warning traceback, making the error message below unnecessary. >> + if (ret) { >> + dev_err(&pdev->dev, "unable to register restart handler, %d\n", ret); >> + return ret; On top of all the above, not registering the poweroff andler in the already impossible case that the restart handler can not be registered seems like an excessively bad idea to me. Guenter >> + } >> pm_power_off = do_msm_poweroff; >> -- 2.34.1 >>
diff --git a/drivers/power/reset/msm-poweroff.c b/drivers/power/reset/msm-poweroff.c index b9a401bd280b..5877a1ba2778 100644 --- a/drivers/power/reset/msm-poweroff.c +++ b/drivers/power/reset/msm-poweroff.c @@ -35,11 +35,16 @@ static void do_msm_poweroff(void) static int msm_restart_probe(struct platform_device *pdev) { + int ret = -EINVAL; msm_ps_hold = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(msm_ps_hold)) return PTR_ERR(msm_ps_hold); - register_restart_handler(&restart_nb); + ret = register_restart_handler(&restart_nb); + if (ret) { + dev_err(&pdev->dev, "unable to register restart handler, %d\n", ret); + return ret; + } pm_power_off = do_msm_poweroff; -- 2.34.1