linux-kernel - Re: [PATCH v4 3/4] mfd: tps6586x: use devm-based power off handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 Apr 2023 13:42:53 +0300
From:   Dmitry Osipenko <dmitry.osipenko@...labora.com>
To:     Benjamin Bara <bbara93@...il.com>
Cc:     Wolfram Sang <wsa@...nel.org>, Lee Jones <lee@...nel.org>,
        rafael.j.wysocki@...el.com, peterz@...radead.org,
        jonathanh@...dia.com, Richard Leitner <richard.leitner@...ux.dev>,
        treding@...dia.com, linux-kernel@...r.kernel.org,
        linux-i2c@...r.kernel.org, linux-tegra@...r.kernel.org,
        Benjamin Bara <benjamin.bara@...data.com>
Subject: Re: [PATCH v4 3/4] mfd: tps6586x: use devm-based power off handler

On 4/14/23 09:15, Benjamin Bara wrote:
> On Thu, 13 Apr 2023, 22:37 Dmitry Osipenko,
> <dmitry.osipenko@...labora.com> wrote:
>> Handlers must return NOTIFY_DONE or notifier_from_errno(). Sorry for
>> missing this previously.
> 
> Thanks!
> 
> AFAIU, notifier_from_errno() sets NOTIFY_STOP_MASK, which stops
> atomic_notifier_call_chain() immediately. So I think NOTIFY_DONE is the
> only valid return value for sys_off handlers, to not skip others. So I
> think letting sys_off_notify() [1] always return NOTIFY_DONE might be a
> good idea.
> 
> If so, we could return a "notify return errno" (or also a "normal
> errno") from the handler, which is checked, but then replaced to
> NOTIFY_DONE, in [1]. This would enable us to have a common place to
> check for failed handlers.
> 
> Handlers then should only return NOTIFY_DONE when they are skipped (e.g.
> when the requested reboot mode is not supported by the handler).
> Otherwise, I think ETIME, ENOSYS or ENOTSUPP might fit when the
> communication was successful, a possible delay awaited, but the return
> was still reached. What do you think?

The behaviour may depend on a particular platform and driver. In general
and in case of this driver, it should be more reliable and cleaner to
abort the reboot on a error that shall never happen.

-- 
Best regards,
Dmitry