linux-kernel - Re: [PATCH] kexec: Export kexec_in

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] [day] [month] [year] [list]

Date:   Fri, 21 Oct 2016 11:48:24 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org, sfr@...b.auug.org.au
Subject: Re: [PATCH] kexec: Export kexec_in_progress to modules

On 10/21/2016 11:37 AM, Eric W. Biederman wrote:
> David Miller <davem@...emloft.net> writes:
> 
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Fri, 21 Oct 2016 00:26:55 -0500
>>
>>> So as far as I can tell you are advocating for a change to support a
>>> driver doing something that is completely pointless.  So no let's not
>>> export this symbol.  Please fix the driver to do something less
>>> pointless instead.
>>
>> FLorian explained his reasoning for doing what he is doing in this
>> specific driver and it made sense to me.
> 
> What doesn't make sense to me is not doing that for any other kind of
> reboot.
> 
> Of the 3 uses of kexec_in_progres in the kernel (not counting this one)
> I think there is only one of them that is really valid.   And that one
> is only valid because it is the least horrible thing the pci layer can
> do.  (AKA it is a hack even there).
> 
> It really is nonsense having methods do different things depending on
> context and that is why kexec_in_progress is not exeported.
> 
> As far as I can tell the use of kexec_in_progress winds up being
> a fragile hack that will just cause more problems later on.
> 
> Florian is there a good readon why you don't just do?

Checking kexec_in_progress allowed not to turn the PHY on for a normal
reboot case, since we don't necessarily know when it will be
re-initialized next, so in that sense it's a power optimization that is
nice to have.

> 
> static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
> {
>         struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
> 
> 	/* For a kernel about to be kexec'd we want to keep the GPHY on for a
>          * successful MDIO bus scan to occur. If we did turn off the GPHY
> 	 * before (e.g: port_disable), this will also power it back on.
> 	 */
> 	if (priv->hw_params.num_gphy == 1)
> 		bcm_sf2_gphy_enable_set(priv->dev->ds, true);
> }
> 
> I certainly don't see anything in the changelog to explain why that
> isn't done.

That would result in an identical behavior for what I am after, David,
shall I send a revert plus this?
-- 
Florian