Re: [PATCH net-next v18 09/10] net: ethtool: Introduce ethtool command to list ports

[Maxime Chevallier]

Hi Jakub,

On 10/1/26 00:40, Jakub Kicinski wrote:
> On Tue, 29 Sep 2026 00:38:45 +0000 netdev-bot+sashiko@xxxxxxxxxx wrote:
>> Thank you for your contribution! Sashiko AI review found 4 potential
>> issue(s) to consider.
>>
>> Critical: 0 · High: 0 · Medium: 3 · Low: 1
>>
>> If you believe none of the issues are legitimate, please reply to each
>> issue of Medium severity or higher and explain why the AI is wrong.
>> If any of them are legitimate and you plan to respin, please let patchwork
>> know by including "pw-bot: cr" as a separate line at the end of your reply
>> (one such reply per series is enough).
>>
>> - [Medium] ETHTOOL_A_PORT_SUPPORTED_INTERFACES is sent as an ethtool
>>   bitset.
> 
> sounds legit, why not expose it?
> 
>> - [Medium] In the unfiltered PORT_GET dump, ctx->pos_portid is carried
>>   from one dumpit() call to the next without recording which device it…
> 
> Also right, we fixed it in other places. Off the top of my head fix
> like this:
> 
> 	int start_ifindex = ctx->pos_ifindex;
> 
> 	...
> 
> 	for..dump(&ctx->pos_ifindex) {
> 		...
> 		if (start_ifindex != ctx->pos_ifindex)
> 			ctx->the_other_pos = 0;
> 		...
> 	}
> 
>> - [Medium] port_dump_one_dev() reads dev->link_topo twice (the NULL
>>   check, then &dev->link_topo->ports) and walks the ports xarray with no…
> 
> didn't look into this one but sounds legit-ish
> 
>> - [Low] The ETHTOOL_MSG_PORT_GET genl_ops entry in net/ethtool/netlink.c
>>   uses ethnl_port_get_policy for both doit and dumpit.
> 
> That's right, please fix, IDK why AI thinks its low.
> You can reject it in the code (start callback)
> or have a separate policy.

Ok I'll fix the above :)

Thanks for looking at this,

Maxime