linux-kernel - Re: [PATCH v1] net: phy: fix motorcomm module automatic loading

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: <CAMdYzYrFuMw4aj_9L698ZhL7Xqy8=NeXhy9HDz4ug-v3=f4fpw@mail.gmail.com>
Date:   Fri, 29 Apr 2022 08:51:54 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] net: phy: fix motorcomm module automatic loading

On Mon, Feb 28, 2022 at 7:44 PM Peter Geis <pgwipeout@...il.com> wrote:
>
> On Mon, Feb 28, 2022 at 7:14 PM Russell King (Oracle)
> <linux@...linux.org.uk> wrote:
> >
> > On Mon, Feb 28, 2022 at 06:30:57PM -0500, Peter Geis wrote:
> > > The sentinel compatible entry whitespace causes automatic module loading
> > > to fail with certain userspace utilities. Fix this by removing the
> > > whitespace and sentinel comment, which is unnecessary.
> >
> > Umm. How does it fail?
>
> It simply does not auto load the module by device id match.
> Manually loading the module after the fact works fine.
>
> >
> > >  static const struct mdio_device_id __maybe_unused motorcomm_tbl[] = {
> > >       { PHY_ID_MATCH_EXACT(PHY_ID_YT8511) },
> > > -     { /* sentinal */ }
> > > +     {}
> >
> > These two should be 100% identical in terms of the object code produced,
> > and thus should have no bearing on the ability for the module to be
> > loaded.
> >
> > Have you investigated the differences in the produced object code?
>
> Yes, you are correct, I just compared the produced files and they are identical.
> This patch can get dropped then.
> I'm curious now why it seemed to make a difference.
>
> I am not familiar enough with how the various userspace elements
> decide to match the modules to determine exactly why this is failing.
> It seems to be hit or miss if userspace decides to auto load this, for
> instance Ubuntu 20.04 was happy to load my kernel module built with
> the arm64 official toolchain, but Manjaro will not load their self
> built kernel module.
> I originally suspected it was due to the manufacturer id being all zeros.
> Unless there's some weird compiler optimization that I'm not seeing in
> my configuration.
>
> Any ideas would be appreciated.
> Thanks!

Good Morning,

After testing various configurations I found what is actually
happening here. When libphy is built in but the phy drivers are
modules and not available in the initrd, the generic phy driver binds
here. This allows the phy to come up but it is not functional. It also
prevents the module driver from binding when it becomes available.
https://elixir.bootlin.com/linux/v5.18-rc4/source/drivers/net/phy/phy_device.c#L1383

It seems there is an implicit dependency between phy_device and the
device specific drivers that isn't realized in the configuration.

I can think of a few ways to fix this, but I think the simplest is to
make the device specific drivers have a kconfig dependency on libphy
(which builds phy_device). This means that the only time the device
specific phy drivers can be modules is if libphy is as well, otherwise
if libphy is built in, the device specific drivers would need to be as
well. There are more elegant and complicated solutions I can think of
here, such as breaking out the generic driver as a module or having a
device-tree flag that annotates that we need a device specific driver.

This isn't realized with most of the common devices such as the
Realtek driver because they have cross dependencies that ensure they
are likely to be built in.

Very Respectfully,
Peter Geis

>
> > If not, please do so, and describe what they were. Thanks.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!