netdev - Re: [net-next] net: phy: fix issue with loading PHY driver w/o initramfs

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:   Wed, 23 Jan 2019 11:06:42 +0100
From:   Geert Uytterhoeven <geert+renesas@...der.be>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [net-next] net: phy: fix issue with loading PHY driver w/o initramfs

From: Geert Uytterhoeven <geert@...ux-m68k.org>

	Hi Heiner,

> On 22.01.2019 23:45, David Miller wrote:
> > From: Heiner Kallweit <hkallweit1@...il.com>
> > Date: Sat, 19 Jan 2019 10:30:21 +0100
> >
> >> It was reported that on a system with nfsboot and w/o initramfs network
> >> fails because trying to load the PHY driver returns -ENOENT. Reason was
> >> that due to missing initramfs the modprobe binary isn't available.
> >> So we have to ignore error code -ENOENT.
> >>
> >> Fixes: 13d0ab6750b2 ("net: phy: check return code when requesting PHY driver module")
> >> Reported-by: Krzysztof Kozlowski <krzk@...nel.org>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
> >
> > Applied.
> >
> > However, I agree with Geert that we should adopt the:
> >
> > 	if (module_not_present)
> > 		request_module();
> > 	if (module_not_present)
> > 		goto failed_to_load;
> >
> > pattern.
>
> I know this is the standard pattern for request_module().
> Unfortunately the situation is a little bit tricky with PHY drivers.
> We don't know whether there's a module matching the PHY ID and
> it's a valid use case that there's no such module.
> In such a case we bind the genphy driver later, and a lot of PHY's
> are totally happy with the genphy driver and therefore no dedicated
> PHY drivers exist.

Currently, if request_module() fails (for whatever reason, except
-ENOENT), you don't bind to the genphy driver, but propagate an
error[*], leaving the user without network interface.

Is that better than ignoring the error, and binding to the genphy
driver?
When do you expect the phy-specific driver to become available, if
ever?

[*] The actual error code returned by request_module(), and not
    -EPROBE_DEFER.  The latter may sound attractive, as it is meant to
    cause a retry later, but has its own set of problems with optional
    drivers that may never become available (e.g. missing drivers for
    DMA controllers).

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds