|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6 |
|
| #
8ef890df |
| 07-Mar-2025 |
Jakub Kicinski <[email protected]> |
net: move misc netdev_lock flavors to a separate header
Move the more esoteric helpers for netdev instance lock to a dedicated header. This avoids growing netdevice.h to infinity and makes rebuildin
net: move misc netdev_lock flavors to a separate header
Move the more esoteric helpers for netdev instance lock to a dedicated header. This avoids growing netdevice.h to infinity and makes rebuilding the kernel much faster (after touching the header with the helpers).
The main netdev_lock() / netdev_unlock() functions are used in static inlines in netdevice.h and will probably be used most commonly, so keep them in netdevice.h.
Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
| #
2bcf4772 |
| 05-Mar-2025 |
Jakub Kicinski <[email protected]> |
net: ethtool: try to protect all callback with netdev instance lock
Protect all ethtool callbacks and PHY related state with the netdev instance lock, for drivers which want / need to have their ops
net: ethtool: try to protect all callback with netdev instance lock
Protect all ethtool callbacks and PHY related state with the netdev instance lock, for drivers which want / need to have their ops instance-locked. Basically take the lock everywhere we take rtnl_lock. It was tempting to take the lock in ethnl_ops_begin(), but turns out we actually nest those calls (when generating notifications).
Tested-by: Maxime Chevallier <[email protected]> Cc: Saeed Mahameed <[email protected]> Signed-off-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
|
Revision tags: v6.14-rc5 |
|
| #
637399bf |
| 01-Mar-2025 |
Maxime Chevallier <[email protected]> |
net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device
ethnl_req_get_phydev() is used to lookup a phy_device, in the case an ethtool netlink command targets a specific phydev within a n
net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device
ethnl_req_get_phydev() is used to lookup a phy_device, in the case an ethtool netlink command targets a specific phydev within a netdev's topology.
It takes as a parameter a const struct nlattr *header that's used for error handling :
if (!phydev) { NL_SET_ERR_MSG_ATTR(extack, header, "no phy matching phyindex"); return ERR_PTR(-ENODEV); }
In the notify path after a ->set operation however, there's no request attributes available.
The typical callsite for the above function looks like:
phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER], info->extack);
So, when tb is NULL (such as in the ethnl notify path), we have a nice crash.
It turns out that there's only the PLCA command that is in that case, as the other phydev-specific commands don't have a notification.
This commit fixes the crash by passing the cmd index and the nlattr array separately, allowing NULL-checking it directly inside the helper.
Fixes: c15e065b46dc ("net: ethtool: Allow passing a phy index for some commands") Signed-off-by: Maxime Chevallier <[email protected]> Reviewed-by: Kory Maincent <[email protected]> Reported-by: Parthiban Veerasooran <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
|
Revision tags: v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11 |
|
| #
1ad84a15 |
| 13-Sep-2024 |
Maxime Chevallier <[email protected]> |
net: ethtool: phy: Don't set the context dev pointer for unfiltered DUMP
The context info allows continuing DUMP requests, shall they fill the netlink buffer.
In the case of filtered DUMP requests,
net: ethtool: phy: Don't set the context dev pointer for unfiltered DUMP
The context info allows continuing DUMP requests, shall they fill the netlink buffer.
In the case of filtered DUMP requests, a reference on the netdev is grabbed in the .start() callback and release in .done().
Unfiltered DUMP request don't need the dev pointer to be set in the context info, doing so will trigger an unwanted netdev_put() in .done().
Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Fixes: 17194be4c8e1 ("net: ethtool: Introduce a command to list PHYs on an interface") Signed-off-by: Maxime Chevallier <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
| #
fce1e9f8 |
| 10-Sep-2024 |
Maxime Chevallier <[email protected]> |
net: ethtool: phy: Check the req_info.pdn field for GET commands
When processing the netlink GET requests to get PHY info, the req_info.pdn pointer is NULL when no PHY matches the requested paramete
net: ethtool: phy: Check the req_info.pdn field for GET commands
When processing the netlink GET requests to get PHY info, the req_info.pdn pointer is NULL when no PHY matches the requested parameters, such as when the phy_index is invalid, or there's simply no PHY attached to the interface.
Therefore, check the req_info.pdn pointer for NULL instead of dereferencing it.
Suggested-by: Eric Dumazet <[email protected]> Reported-by: Eric Dumazet <[email protected]> Closes: https://lore.kernel.org/netdev/CANn89iKRW0WpGAh1tKqY345D8WkYCPm3Y9ym--Si42JZrQAu1g@mail.gmail.com/T/#mfced87d607d18ea32b3b4934dfa18d7b36669285 Fixes: 17194be4c8e1 ("net: ethtool: Introduce a command to list PHYs on an interface") Signed-off-by: Maxime Chevallier <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5 |
|
| #
17194be4 |
| 21-Aug-2024 |
Maxime Chevallier <[email protected]> |
net: ethtool: Introduce a command to list PHYs on an interface
As we have the ability to track the PHYs connected to a net_device through the link_topology, we can expose this list to userspace. Thi
net: ethtool: Introduce a command to list PHYs on an interface
As we have the ability to track the PHYs connected to a net_device through the link_topology, we can expose this list to userspace. This allows userspace to use these identifiers for phy-specific commands and take the decision of which PHY to target by knowing the link topology.
Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list devices on only one interface.
Signed-off-by: Maxime Chevallier <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Tested-by: Christophe Leroy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
show more ...
|
|
Revision tags: v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7 |
|
| #
63d5eaf3 |
| 21-Dec-2023 |
Maxime Chevallier <[email protected]> |
net: ethtool: Introduce a command to list PHYs on an interface
As we have the ability to track the PHYs connected to a net_device through the link_topology, we can expose this list to userspace. Thi
net: ethtool: Introduce a command to list PHYs on an interface
As we have the ability to track the PHYs connected to a net_device through the link_topology, we can expose this list to userspace. This allows userspace to use these identifiers for phy-specific commands and take the decision of which PHY to target by knowing the link topology.
Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list devices on only one interface.
Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
show more ...
|