netdev - Re: ethtool 5.7: netlink ENOENT error when setting WOL

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:   Sun, 14 Jun 2020 09:44:30 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Michal Kubecek <mkubecek@...e.cz>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ethtool 5.7: netlink ENOENT error when setting WOL



On 6/14/2020 9:14 AM, Heiner Kallweit wrote:
> On 10.06.2020 22:05, Andrew Lunn wrote:
>>> Not sure it makes sense to build ETHTOOL_NETLINK as a module, but at
>>> least ensuring that ETHTOOL_NETLINK is built into the kernel if PHYLIB=y
>>> or PHYLIB=m would make sense, or, better we find a way to decouple the
>>> two by using function pointers from the phy_driver directly that way
>>> there is no symbol dependency (but reference counting has to work).
>>
>> Hi Florian
>>
>> It is not so easy to make PHYLIB=m work. ethtool netlink needs to call
>> into the phylib core in order to trigger a cable test, not just PHY
>> drivers.
>>
>> Ideas welcome.
>>
> When looking at functions like phy_start_cable_test() we could do the
> following: Most of it doesn't need phylib and could be moved to
> ethtool/cabletest.c. Or maybe into a separate ethtool phylib glue
> code source file. The phylib calls (phy_link_down, phy_trigger_machine)
> then would have to be moved into the cable_test_start callback.
> I see that each callback implementation then would have some
> boilerplate code. But maybe we could facilitate this with few helpers,
> so that a cable test callback would look like:
> 
> phy_cable_test_boiler_start()
> actual_cable_test()
> phy_cable_test_boiler_end()

Yes, that could work, the other possibility would be to extend
ethtool_ops and add cable_test_start function pointers, and then we just
punt onto the network device driver to call the appropriate PHYLIB
function. That way we already have a mechanism in place for registering
callbacks which is based upon the network device driver lifecycle, and
from the network device driver is guaranteed to load PHYLIB because of
direct symbol dependencies. The caveat with that approach is that each
network device driver needs top opt in for those, as opposed to us
defaulting to using PHYLIB and enabling all drivers that use PHYLIB by
default.
-- 
Florian