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  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:   Tue, 5 Oct 2021 12:42:53 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [RFC net-next PATCH 05/16] net: phylink: Automatically attach PCS
 devices



On 10/5/21 5:48 AM, Russell King (Oracle) wrote:
> On Mon, Oct 04, 2021 at 03:15:16PM -0400, Sean Anderson wrote:
>> This adds support for automatically attaching PCS devices when creating
>> a phylink. To do this, drivers must first register with
>> phylink_register_pcs. After that, new phylinks will attach the PCS
>> device specified by the "pcs" property.
>>
>> At the moment there is no support for specifying the interface used to
>> talk to the PCS. The MAC driver is expected to know how to talk to the
>> PCS. This is not a change, but it is perhaps an area for improvement.
>>
>> I believe this is mostly correct with regard to registering/
>> unregistering. However I am not too familiar with the guts of Linux's
>> device subsystem. It is possible (likely, even) that the current system
>> is insufficient to prevent removing PCS devices which are still in-use.
>> I would really appreciate any feedback, or suggestions of subsystems to
>> use as reference. In particular: do I need to manually create device
>> links? Should I instead add an entry to of_supplier_bindings? Do I need
>> a call to try_module_get?
>
> I think this is an area that needs to be thought about carefully.
> Things are not trivial here.
>
> The first mistake I see below is the use of device links. pl->dev is
> the "struct device" embedded within "struct net_device". This doesn't
> have a driver associated with it, and so using device links is likely
> ineffectual.

So what can the device in net_device be used for?

> Even with the right device, I think careful thought is needed - we have
> network drivers where one "struct device" contains multiple network
> interfaces. Should the removal of a PCS from one network interface take
> out all of them?

Well, it's more of the other way around. We need to prevent removing the
PCS while it is still in-use.

> Alternatively, could we instead use phylink to "unplug" the PCS and
> mark the link down - would that be a better approach than trying to
> use device links?

So here, I think the logic should be: allow phylink to "unplug" the PCS
only when the link is down.

--Sean

Powered by blists - more mailing lists