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]

Message-ID: <CAJpcXm4RRV15UUzsrw_9s4-ifE0W0uKSsZ2sAJxojsoctaT8Ow@mail.gmail.com>
Date:   Fri, 14 Apr 2023 08:15:54 +0200
From:   Benjamin Bara <bbara93@...il.com>
To:     Dmitry Osipenko <dmitry.osipenko@...labora.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 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?

Thanks and best regards,
Benjamin

[1] https://elixir.bootlin.com/linux/v6.3-rc6/source/kernel/reboot.c#L327