linux-kernel - Re: [PATCH v7 2/4] power: reset: add reboot mode driver

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: <570CBF7F.9090300@rock-chips.com>
Date:	Tue, 12 Apr 2016 17:27:27 +0800
From:	Andy Yan <andy.yan@...k-chips.com>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>, robh+dt@...nel.org,
	sre@...nel.org, heiko@...ech.de, john.stultz@...aro.org,
	arnd@...db.de
Cc:	mark.rutland@....com, catalin.marinas@....com, will.deacon@....com,
	alexandre.belloni@...e-electrons.com, f.fainelli@...il.com,
	linux@....linux.org.uk, dbaryshkov@...il.com,
	linux-pm@...r.kernel.org, linux-rockchip@...ts.infradead.org,
	wxt@...k-chips.com, devicetree@...r.kernel.org, pawel.moll@....com,
	ijc+devicetree@...lion.org.uk, lorenzo.pieralisi@....com,
	matthias.bgg@...il.com, linux-arm-kernel@...ts.infradead.org,
	moritz.fischer@...us.com, mbrugger@...e.com,
	linux-kernel@...r.kernel.org, galak@...eaurora.org, olof@...om.net,
	jun.nie@...aro.org, dwmw2@...radead.org
Subject: Re: [PATCH v7 2/4] power: reset: add reboot mode driver

Hi Krzysztof:

On 2016年04月06日 09:00, Krzysztof Kozlowski wrote:
> On 06.04.2016 09:50, Andy Yan wrote:
>
> (...)
>
>>>> +            return -ENOMEM;
>>>> +
>>>> +        info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
>>>> +        if (of_property_read_u32(np, prop->name, &info->magic)) {
>>>> +            dev_err(dev, "reboot mode %s without magic number\n",
>>>> +                info->mode);
>>>> +            devm_kfree(dev, info);
>>>> +            continue;
>>>> +        }
>>>> +        list_add_tail(&info->list, &reboot->head);
>>>> +    }
>>>> +    of_node_put(np);
>>> If you of_node_put() here, there is no sense in getting it before. I
>>> mentioned of_node_get() only because I am not sure about life-cycle of
>>> nodes in case of DT overlays and you are storing the pointer to string
>>> from DT.
>>>
>>> The doubts I have are concerning only the case of freeing nodes from
>>> overlay.
>>>
>>> I don't know if of_node_get() is needed but of_node_get()+of_node_put()
>>> seems useless.
>>
>>   I am also not sure about it. Maybe just drop of_node_get/put ?
> OK, let's drop both get() and put().
>
> (...)
>
>>>> +
>>>> +static const struct of_device_id syscon_reboot_mode_of_match[] = {
>>>> +    { .compatible = "syscon-reboot-mode" },
>>>> +    {}
>>>> +};
>>>> +
>>>> +static struct platform_driver syscon_reboot_mode_driver = {
>>>> +    .probe = syscon_reboot_mode_probe,
>>> Cleanup needed. What will happen after device unbind? Memory will be
>>> released (devm-*()) but reboot notifier won't thus leading to OOPS on
>>> reboot.
>>      From the kernel_restart_prepare function, the reboot notifier will
>> be called before device_shutdown. Is there any other case the device
>> unbind before reboot notifier
>> called?
> This is a regular module platform driver so unbind can happen any time
> initiated by user, either by unbind command or by module removal. User
> can then re-bind device or not - probably does not matter. Anyway after
> such first unbind, the restart will kaboom instead of do a restart.

     I just need to do clean up in remove?
> Beside that, you always should clean up, regardless of restart or not.
> If you do not want unbind (thus no need of cleanup) then forbid it by
> making it a non-module with suppressed bind.
>
> Best regards,
> Krzysztof
>
>
>
>