- 29 Feb, 2024 6 commits
-
-
Jakub Kicinski authored
Eric Dumazet says: ==================== inet: implement lockless RTM_GETNETCONF ops This series removes RTNL use for RTM_GETNETCONF operations on AF_INET. - Annotate data-races to avoid possible KCSAN splats. - "ip -4 netconf show dev XXX" can be implemented without RTNL [1] - "ip -4 netconf" dumps can be implemented using RCU instead of RTNL [1] [1] This only refers to RTM_GETNETCONF operation, "ip" command also uses RTM_GETLINK dumps which are using RTNL at this moment. ==================== Link: https://lore.kernel.org/r/20240227092411.2315725-1-edumazet@google.comSigned-off-by:Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
1) inet_netconf_dump_devconf() can run under RCU protection instead of RTNL. 2) properly return 0 at the end of a dump, avoiding an an extra recvmsg() system call. 3) Do not use inet_base_seq() anymore, for_each_netdev_dump() has nice properties. Restarting a GETDEVCONF dump if a device has been added/removed or if net->ipv4.dev_addr_genid has changed is moot. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227092411.2315725-4-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
"ip -4 netconf show dev XXXX" no longer acquires RTNL. Return -ENODEV instead of -EINVAL if no netdev or idev can be found. Signed-off-by:
-
Eric Dumazet authored
Add READ_ONCE() in ipv4_devconf_get() and corresponding WRITE_ONCE() in ipv4_devconf_set() Add IPV4_DEVCONF_RO() and IPV4_DEVCONF_ALL_RO() macros, and use them when reading devconf fields. Signed-off-by:
-
Catalin Popescu authored
Commit d1d77120 ("net: phy: dp83826: support TX data voltage tuning") introduced a regression in that WOL is not disabled by default for DP83826. WOL should normally be enabled through ethtool. Fixes: d1d77120 ("net: phy: dp83826: support TX data voltage tuning") Signed-off-by:
Catalin Popescu <catalin.popescu@leica-geosystems.com> Link: https://lore.kernel.org/r/20240226162339.696461-1-catalin.popescu@leica-geosystems.comSigned-off-by:
-
Chengming Zhou authored
The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was removed as of v6.8-rc1, so it became a dead flag since the commit 16a1d968 ("mm/slab: remove mm/slab.c and slab_def.h"). And the series[1] went on to mark it obsolete to avoid confusion for users. Here we can just remove all its users, which has no functional change. [1] https://lore.kernel.org/all/20240223-slab-cleanup-flags-v2-1-02f1753e8303@suse.cz/Signed-off-by:
Chengming Zhou <zhouchengming@bytedance.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240228030658.3512782-1-chengming.zhou@linux.devSigned-off-by:
-
- 28 Feb, 2024 34 commits
-
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== tools: ynl: stop using libmnl There is no strong reason to stop using libmnl in ynl but there are a few small ones which add up. First (as I remembered immediately after hitting send on v1), C++ compilers do not like the libmnl for_each macros. I haven't tried it myself, but having all the code directly in YNL makes it easier for folks porting to C++ to modify them and/or make YNL more C++ friendly. Second, we do much more advanced netlink level parsing in ynl than libmnl so it's hard to say that libmnl abstracts much from us. The fact that this series, removing the libmnl dependency, only adds <300 LoC shows that code savings aren't huge. OTOH when new types are added (e.g. auto-int) we need to add compatibility to deal with older version of libmnl (in fact, even tho patches have been sent months ago, auto-ints are still not supported in libmnl.git). Thrid, the dependency makes ynl less self contained, and harder to vendor in. Whether vendoring libraries into projects is a good idea is a separate discussion, nonetheless, people want to do it. Fourth, there are small annoyances with the libmnl APIs which are hard to fix in backward-compatible ways. See the last patch for example. All in all, libmnl is a great library, but with all the code generation and structured parsing, ynl is better served by going its own way. v1: https://lore.kernel.org/all/20240222235614.180876-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240227223032.1835527-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
To stick to libmnl wrappers in the past we had to use poll() to check if there are any outstanding notifications on the socket. This is no longer necessary, we can use MSG_DONTWAIT. Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-16-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
We don't use libmnl any more. Acked-by:
-
Jakub Kicinski authored
Most libmnl socket helpers can be replaced by direct calls to the underlying libc API. We need portid, the netlink manpage suggests we bind() address of zero. Acked-by:
-
Jakub Kicinski authored
Create a local version of the MNL_CB_* parser control values. Acked-by:
-
Jakub Kicinski authored
All YNL parsing callbacks take struct ynl_parse_arg as the argument. Make that official by using a local callback type instead of mnl_cb_t. Acked-by:
-
Jakub Kicinski authored
There's only one set of callbacks in YNL, for netlink control messages, and most of them are trivial. So implement the message walking directly without depending on mnl_cb_run2(). Acked-by:
-
Jakub Kicinski authored
ynl_recv_ack() is simple and it's the only user of mnl_cb_run(). Now that ynl_sock_read_msgs() exists it's actually less code to use ynl_sock_read_msgs() instead of being special. Acked-by:
-
Jakub Kicinski authored
All callers to mnl_cb_run2() call mnl_socket_recvfrom() right before. Wrap the two in a helper, take typed arguments (struct ynl_parse_arg), instead of hoping that all callers remember that parser error handling requires yarg. In case of ynl_sock_read_family() we will no longer check for kernel returning no data, but that would be a kernel bug, not worth complicating the code to catch this. Calling mnl_cb_run2() on an empty buffer is legal and results in STOP (1). Acked-by:
-
Jakub Kicinski authored
Commit f2ba1e5e ("tools: ynl-gen: stop generating common notification handlers") removed the last caller of the parse_cb_run() helper. We no longer need to export ynl_cb_array. Acked-by:
-
Jakub Kicinski authored
All YNL parsing code expects a pointer to struct ynl_parse_arg AKA yarg. For dump was pass in struct ynl_dump_state, which works fine, because struct ynl_dump_state and struct ynl_parse_arg have identical layout for the members that matter.. but it's a bit hacky. Acked-by:
-
Jakub Kicinski authored
libc doesn't have an ARRAY_SIZE() create one locally. Acked-by:
-
Jakub Kicinski authored
Create helpers for accessing payloads of struct nlmsg. Use them instead of the libmnl ones. Acked-by:
-
Jakub Kicinski authored
Create ynl_attr_for_each*() iteration helpers. Use them instead of the mnl ones. Acked-by:
-
Jakub Kicinski authored
Don't use mnl attr helpers, we're trying to remove the libmnl dependency. Create both signed and unsigned helpers, libmnl had unsigned helpers, so code generator no longer needs the mnl_type() hack. The new helpers are written from first principles, but are hopefully not too buggy. Acked-by:
-
Jakub Kicinski authored
The temporary auto-int helpers are not really correct. We can't treat signed and unsigned ints the same when determining whether we need full 8B. I realized this before sending the patch to add support in libmnl. Unfortunately, that patch has not been merged, so time to fix our local helpers. Use the mnl* name for now, subsequent patches will address that. Acked-by:
Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20240227223032.1835527-2-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Since commit 7c59c9c8 ("tools: ynl: generate code for ovs families") we need relatively recent OvS headers to get YNL to compile. Add the direct include workaround to fix compilation on less up-to-date OSes like CentOS 9. Reviewed-by:
-
David S. Miller authored
Andrew Lunn says: ==================== drivers: net: Convert EEE handling to use linkmode bitmaps EEE has until recently been limited to lower speeds due to the use of the legacy u32 for link speeds. This restriction has been lifted, with the use of linkmode bitmaps, added in the following patches: 1f069de6 ethtool: add linkmode bitmap support to struct ethtool_keee 1d756ff1 ethtool: add suffix _u32 to legacy bitmap members of struct ethtool_keee 285cc15c ethtool: adjust struct ethtool_keee to kernel needs 0b3100bc ethtool: switch back from ethtool_keee to ethtool_eee for ioctl d80a5233 ethtool: replace struct ethtool_eee with a new struct ethtool_keee on kernel side This patchset converts the remaining MAC drivers still using the old _u32 to link modes. A couple of Intel drivers do odd things with EEE, setting the autoneg bit. It is unclear why, no other driver does, ethtool does not display it, and EEE is always negotiated. One patch in this series deletes this code. With all users of the legacy _u32 changed to link modes, the _u32 values are removed from keee, and support for them in the ethtool core is removed. --- Changes in v5: - Restore zeroing eee_data.advertised in ax8817_178a - Fix lp_advertised -> supported in ixgdb - Link to v4: https://lore.kernel.org/r/20240218-keee-u32-cleanup-v4-0-71f13b7c3e60@lunn.ch Changes in v4: - Add missing conversion in igb - Add missing conversion in r8152 - Add patch to remove now unused _u32 members - Link to v3: https://lore.kernel.org/r/20240217-keee-u32-cleanup-v3-0-fcf6b62a0c7f@lunn.ch Changes in v3: - Add list of commits adding linkmodes to EEE to cover letter - Fix grammar error in cover letter. - Add Reviewed-by from Jacob Keller - Link to v2: https://lore.kernel.org/r/20240214-keee-u32-cleanup-v2-0-4ac534b83d66@lunn.ch Changes in v2: - igb: Fix type 100BaseT to 1000BaseT. - Link to v1: https://lore.kernel.org/r/20240204-keee-u32-cleanup-v1-0-fb6e08329d9a@lunn.ch ==================== Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
All MAC drivers have been converted to use the link mode members of keee. So remove the _u32 values, and the code in the ethtool core to convert the legacy _u32 values to link modes. Reviewed-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by:
-
Andrew Lunn authored
Energy Efficient Ethernet should always be negotiated with the link peer. Don't include SUPPORTED_Autoneg in the results of get_eee() for supported, advertised or lp_advertised, since it is assumed. Additionally, ethtool(1) ignores the set bit, and no other driver sets this. Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Andrew Lunn authored
Convert the tables to make use of ETHTOOL link mode bits, rather than the old u32 SUPPORTED speeds. Make use of the linkmode helps to set bits and compare linkmodes. As a result, the _u32 members of keee are no longer used, a step towards removing them. Signed-off-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for bit manipulation of EEE advertise, support and link partner support. The aim is to drop the restricted _u32 variants in the near future. Reviewed-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Signed-off-by:
-
Andrew Lunn authored
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Rework determining if EEE is active to make is similar as to how phylib decides, and make use of a phylib helper to validate if EEE is valid in for the current link mode. This then requires that PHYLIB is selected. Reviewed-by:
-
Zhengchao Shao authored
The input parameter 'level' in rawv6_get/seticmpfilter is not used. Therefore, remove it. Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
-
Sarosh Hasan authored
Updating link clock rate for different speeds is only needed when using RGMII, as that mode requires changing clock speed when the link speed changes. Let's restrict updating the link clock speed in ethqos_update_link_clk() to just RGMII. Other modes such as SGMII only need to enable the link clock (which is already done in probe). Signed-off-by:
Sarosh Hasan <quic_sarohasa@quicinc.com> Reviewed-by:
Andrew Halaney <ahalaney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8775p-ride Reviewed-by:
Abhishek Chauhan <quic_abchauha@quicinc.com> Signed-off-by:
-
David S. Miller authored
Justin Iurman says: ==================== ioam6: netlink multicast event v5: - remove the "must be the destination" check before sending an ioam6 event v4: - rebase on top of net merge v3: - patchset was mistakenly superseded due to same cover title used for iproute2-next equivalent patch -> resend (renamed) v2: - fix warnings Add generic netlink multicast event support to ioam6 as another solution to share IOAM data with user space. The other one being via IPv6 raw sockets combined with ancillary data (or packet socket, if the listener does not need the processing of the IOAM Option-Type, since the hook is before in that case). This patchset focuses on the IOAM Pre-allocated Trace (the only Option-Type currently supported in the kernel), and so on IOAM "trace" events. See an example of a consumer here [1]. [1] https://github.com/Advanced-Observability/ioam-agent-python/blob/netlink_event/ioam-agent.py ==================== Signed-off-by:
-
Justin Iurman authored
If we're processing an IOAM Pre-allocated Trace Option-Type (the only one supported currently), then send the trace as an ioam6 event to the netlink multicast group. This way, user space apps will be able to collect IOAM data. Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
Justin Iurman <justin.iurman@uliege.be> Signed-off-by:
-
Justin Iurman authored
Add a multicast group to the ioam6 generic netlink family and provide ioam6_event() to send an ioam6 event to the multicast group. Reviewed-by:
-
Justin Iurman authored
Add new api to support ioam6 events for generic netlink multicast. A first "trace" event is added to the list of ioam6 events, which will represent an IOAM Pre-allocated Trace Option-Type. It provides another solution to share IOAM data with user space. Reviewed-by:
-
Krzysztof Kozlowski authored
dtschema defines label as string, so $ref in other bindings is redundant. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
