Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [RFC PATCH net-next 3/9] net: pcs: Add helpers for registering
 and finding PCSs
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>, netdev@vger.kernel.org,
        Jakub Kicinski <kuba@kernel.org>,
        Madalin Bucur <madalin.bucur@nxp.com>,
        "David S . Miller" <davem@davemloft.net>,
        Paolo Abeni <pabeni@redhat.com>,
        Ioana Ciornei <ioana.ciornei@nxp.com>,
        linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Frank Rowand <frowand.list@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Saravana Kannan <saravanak@google.com>,
        devicetree@vger.kernel.org
References: <20220711160519.741990-1-sean.anderson@seco.com>
 <20220711160519.741990-4-sean.anderson@seco.com>
 <YsyPGMOiIGktUlqD@shell.armlinux.org.uk>
 <3aad4e83-4aee-767e-b36d-e014582be7bd@seco.com>
 <Ys2Yiis53M+Lb9rR@shell.armlinux.org.uk>
From:   Sean Anderson <sean.anderson@seco.com>
Message-ID: <17579747-34f7-b927-ee1e-b25a216431e0@seco.com>
Date:   Tue, 12 Jul 2022 19:15:12 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
In-Reply-To: <Ys2Yiis53M+Lb9rR@shell.armlinux.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OCtKRDhiNk12RWcwZ2cwVVNENkdLbWZCaWcxdXpqdFo4U2ZmZURvUDBCMnBk?=
 =?utf-8?B?VGdhd1N0RTZteEVkQktvZVg1eWtQT0p2VHZhVkZ0RXNsTVZERXpGRTRBb3R4?=
 =?utf-8?B?UWJJM2U4V2RoWnhoazhZaFpBUFhzWHY2TWdFVDZ2YzNNVHVaOTQvcTFqZzdm?=
 =?utf-8?B?Wno5dUI4ankxL0hIVDg5cUo0UGdTQnduSk8yOVlib3lTelEzQlk3WHFONU9o?=
 =?utf-8?B?NDNWbU9lUVhianJySXorclMrUlRJRGpkVmNlNmorRlZwdG9FRXUyNVpOM0E4?=
 =?utf-8?B?d1V0MXhiZTJpbW9vNGloRXF2dEF3MHRkczZjSG9lVDVKbHRlc3BXUHo4ZTNV?=
 =?utf-8?B?NDV3WnVsczVQQ25qMGNWTjdnU085SGJUcU5VRy8vMTlucXQ5ZEx4bGFTT1J1?=
 =?utf-8?B?ZUlpU3g0enNDWDk2QnlHM1hjY0pZWEN2ZkVMMUljbjRxSTJ1UGdjcXhTVXhL?=
 =?utf-8?B?ajliME11WmIwamlFMUdXRXRFSUVXRnFWTkFCcUVQN0Vhays1aDZiU2s5L2VO?=
 =?utf-8?B?VFR6ZzIrMUZ0STFQTGlhby9uMGxmOWU0NjFlTHF3TVJCTU5KTmpVR0wvb1N2?=
 =?utf-8?B?cVNETzZ3dE9ybFRzZ2tqS0dXTVVqdjNuU0lCdE0vMG43Z0s0d1phMDlqc3NZ?=
 =?utf-8?B?dE0vaEdGVUoxRTM5RVp1SC9peGlpTS9KUVJUMVVNVUV1anRuUHBDeWZOUHFZ?=
 =?utf-8?B?VHRrWkFSbGYvMUpjR0lOS2pZM28vSGtjZUpvZ2x1eFRtT2l3N1lEK3g2WHhw?=
 =?utf-8?B?cXhCWTBnZkoycU9FUE5RejNEanZlUDFpMWg3YXFKK3B2dklOYmRFWlNLclNO?=
 =?utf-8?B?T00zODVYTWZBSWJza01GUUlpTk9HSUdVNm9FQ1BWSjloQmRXR2Q2ZW5rTzNK?=
 =?utf-8?B?TzRsUUFJU2xLY3lMWEF1Q0l2MkFaMVNZL1R3TlQ0SWZQRW1tbXkwdXdQZS95?=
 =?utf-8?B?eXduYnU3eEhHT0pHUmNmOHBkdkFQY05KNlJRcDFHUU1aWjUrSXVSbS9DNjRI?=
 =?utf-8?B?NE9TcnZ6YTZjWUZod2FGc3ViV3lLMVQwNXZMOFZKanZKM0ZPWWpCbmRTeXdD?=
 =?utf-8?B?eWEyTm8xNlBITFVTVWUrTXFNcU5ONE9GcnBpbm80Y295NUpEVWhsWmVRbjhE?=
 =?utf-8?B?T05VUDdPVldYeHB2blBQN3JuRzBYdFBjU1VnRTBDY3ptOStIWWg1dHdLSWcr?=
 =?utf-8?B?endtVWVrUEVFZ0hWUlQvMDF4T29wTHB5Y2dyT2h3VFV2OUJnY1B3QWFNd1Rv?=
 =?utf-8?B?RGRCOE1pR0lDWS9KQ3I5T2I3dDBqb2tCQlFHbnZBWkg3QmhrK2lPQnVKT2hT?=
 =?utf-8?B?Ri8rV0hDVEJucEQrWVJaTFhFN3I3cW5RUXZsQ0VKQmtqaTFjM2J2ZGpGaG9O?=
 =?utf-8?B?ZFFRRCtnbC9Bdlo3QkNXT1dEMWZJaVFCTCtTNExvT2EydlN6WnE5cnpFaFYz?=
 =?utf-8?B?YTNCa2xxN3lObGpudWNHZEVKWmEzSUJWNCtIMUFIWXduWGJPdm5VTDluZUVv?=
 =?utf-8?B?UmxnUkJzRmsvTzhZbVBRa1lmMzRnQWFhZ1I3Y3BEZ2FiQ3YzRG00NTl6aWxq?=
 =?utf-8?B?SzZVb2NuU3h2YlRKT0hFdlhXbHRFWksvbHRjYUZaRGJLODdhN3VOcDg5eHFi?=
 =?utf-8?B?L3Z6N2tyRWtnWXhhTW9iS1B0VVQxaEhqR3JZdldLSFpDL0Qvd1lLU1dJWnRr?=
 =?utf-8?B?K1dacmt3SU0zeCtrWGhKV09EdWdtUHVMelVnSWZDTGtpN0c3L1dvTndNYzJP?=
 =?utf-8?B?T1owUmlBT29ZeDlPWWxwVEc2bGRTdldQZHZwN2FxMkRYS1ZGRnZSbjVITFVk?=
 =?utf-8?B?NzVqVmNLQ2JDSE9vZXp5V1NDWUo4ZXQwYTBoaUpTZmtYcytPclNWbEYzZk1x?=
 =?utf-8?B?ODJSeWRHOTJtMGZSTG1FNHlLZFVrYnc4ZU0yeG1lVXp6TkZsTEpKUm5SV2lE?=
 =?utf-8?B?a1Avekg1MWczSXo5U1RJVDlFZHRwamhLbVFWY3FVdEc5Z1RTZXB6anNRcFQw?=
 =?utf-8?B?QUFNQ0RSUm1ocFJ0Q29FRDh6UktSclA2VEZPRVJQMklBd0tDNy8zTXREU1N3?=
 =?utf-8?B?MFFOWVg1cGJHWVM1TmZRUzl2OWxHWk1XbkdTZk1qVmhNUSszNk1lK0tLaUQ1?=
 =?utf-8?B?N1F1a0xSVDBtUmhwL3BNR29jdnNPUzhVQnpUZ3YwK2xlak13TmxGM3UybU9F?=
 =?utf-8?B?SkE9PQ==?=
X-OriginatorOrg: seco.com
X-MS-Exchange-CrossTenant-Network-Message-Id: faab3eee-6e14-4974-ff1d-08da645c62ef
X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB4972.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2022 23:15:18.7104
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bebe97c3-6438-442e-ade3-ff17aa50e733
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: a1Nfj7Ybh5+C/2vXFFxQB0uAU8fwZBjIUaXgS5ZJjg8GfIdU7al5d9iA4tRzgq9TALXZft0xgbYW74pZqORW9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR03MB2954
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,
        SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 7/12/22 11:51 AM, Russell King (Oracle) wrote:
> On Mon, Jul 11, 2022 at 05:47:26PM -0400, Sean Anderson wrote:
>> Hi Russell,
>> 
>> On 7/11/22 4:59 PM, Russell King (Oracle) wrote:
>> > Hi Sean,
>> > 
>> > It's a good attempt and may be nice to have, but I'm afraid the
>> > implementation has a flaw to do with the lifetime of data structures
>> > which always becomes a problem when we have multiple devices being
>> > used in aggregate.
>> > 
>> > On Mon, Jul 11, 2022 at 12:05:13PM -0400, Sean Anderson wrote:
>> >> +/**
>> >> + * pcs_get_tail() - Finish getting a PCS
>> >> + * @pcs: The PCS to get, or %NULL if one could not be found
>> >> + *
>> >> + * This performs common operations necessary when getting a PCS (chiefly
>> >> + * incrementing reference counts)
>> >> + *
>> >> + * Return: @pcs, or an error pointer on failure
>> >> + */
>> >> +static struct phylink_pcs *pcs_get_tail(struct phylink_pcs *pcs)
>> >> +{
>> >> +	if (!pcs)
>> >> +		return ERR_PTR(-EPROBE_DEFER);
>> >> +
>> >> +	if (!try_module_get(pcs->ops->owner))
>> >> +		return ERR_PTR(-ENODEV);
>> > 
>> > What you're trying to prevent here is the PCS going away - but holding a
>> > reference to the module doesn't prevent that with the driver model. The
>> > driver model design is such that a device can be unbound from its driver
>> > at any moment. Taking a reference to the module doesn't prevent that,
>> > all it does is ensure that the user can't remove the module. It doesn't
>> > mean that the "pcs" structure will remain allocated.
>> 
>> So how do things like (serdes) phys work? Presumably the same hazard
>> occurs any time a MAC uses a phy, because the phy can disappear at any time.
>> 
>> As it happens I can easily trigger an Oops by unbinding my serdes driver
>> and the plugging in an ethernet cable. Presumably this means that the phy
>> subsystem needs the devlink treatment? There are already several in-tree
>> MAC drivers using phys...
> 
> It's sadly another example of this kind of thing. When you consider
> that the system should operate in a safe manner with as few "gotchas"
> as possible, then being able to "easily trigger an Oops" is something
> that we should be avoiding. It's not hard to avoid - we have multiple
> mechanisms in the kernel now to deal with it. 

OK, so as mentioned above this exists in several MAC drivers already. How do
you propose to fix this?

> We have the component
> helper. We have devlinks. We can come up with other solutions such
> as what I mentioned in my previous reply (which I consider to be the
> superior solution in this case - because it doesn't mess up cases
> where a single struct device is associated with multiple network
> devices (such as on Armada 8040 based systems.)
> 
> It's really about "Quality of Implementation" - and I expect high
> quality. I don't want my systems crashing because I've tried to
> temporarily unbind some device.
> 
>> > The second issue that this creates is if a MAC driver creates the PCS
>> > and then "gets" it through this interface, then the MAC driver module
>> > ends up being locked in until the MAC driver devices are all unbound,
>> > which isn't friendly at all.
>> 
>> The intention here is not to use this for "internal" PCSs, but only for
>> external ones. I suppose you're referring to 
> 
> I wish I could say that intentions for use bear the test of time, but
> sadly I can not.

Well, we can burn that bridge when we come to it. For now, yes if you call
pcs_get_by_* from the same device where you call pcs_register then the device
will be "locked in".

>> > So, anything that proposes to create a new subsystem where we have
>> > multiple devices that make up an aggregate device needs to nicely cope
>> > with any of those devices going away. For that to happen in this
>> > instance, phylink would need to know that its in-use PCS for a
>> > particular MAC is going away, then it could force the link down before
>> > removing all references to the PCS device.
>> > 
>> > Another solution would be devlinks, but I am really not a fan of that
>> > when there may be a single struct device backing multiple network
>> > interfaces, where some of them may require PCS and others do not. One
>> > wouldn't want the network interface with nfs-root to suddenly go away
>> > because a PCS was unbound from its driver!
>> 
>> Well, you can also do
>> 
>> echo "mmc0:0001" > /sys/bus/mmc/drivers/mmcblk/unbind
>> 
>> which will (depending on your system) have the same effect.
>> 
>> If being able to unbind any driver at any time is intended,
>> then I don't think we can save userspace from itself.
> 
> If you unbind the device that contains your rootfs, you are absolutely
> correct. It's the same as taking down the network interface that gives
> you access to your NFS root.
> 
> However, neither of these cause the kernel to crash - they make
> userspace unusable.
> 
> So, let's say that it is acceptable that the kernel crashes if one
> unbinds a device. Why then bother with try_module_get() - if the user
> is silly enough to remove the module containing the PCS code, doesn't
> the same argument apply? "Shouldn't have done that then."
> 
> I don't see the logic.
> 

This was in response to your opposition to using devlink to manage the
PCS, since it would unbind the MAC as well. So what would happen here is
that someone would unbind the PCS, which would in turn unbind the MAC,
having the same effect as if the user manually unbound the MAC directly.

If you really want to avoid this, we'd need some kind of callback from
devlink to allow the MAC to say "well, I wasn't using that PCS anyway,"
or at the very least "let me clean up this (soon-to-be) dangling pointer."

--Sean