- 06 Jan, 2024 3 commits
-
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2024-01-05 We've added 40 non-merge commits during the last 2 day(s) which contain a total of 73 files changed, 1526 insertions(+), 951 deletions(-). The main changes are: 1) Fix a memory leak when streaming AF_UNIX sockets were inserted into multiple sockmap slots/maps, from John Fastabend. 2) Fix gotol in s390 BPF JIT with large offsets, from Ilya Leoshkevich. 3) Fix reattachment branch in bpf_tracing_prog_attach() and reject the request if there is no valid attach_btf, from Jiri Olsa. 4) Remove deprecated bpfilter kernel leftovers given the project is developed in user space (https://github.com/facebook/bpfilter), from Quentin Deslandes. 5) Relax tracing BPF program recursive attach rules given right now it is not possible to create tracing program call cycles, from Dmitrii Dolgov. 6) Fix excessive memory consumption for the bpf_global_percpu_ma for systems with a large number of CPUs, from Yonghong Song. 7) Small x86 BPF JIT cleanup to reuse emit_nops instead of open-coding memcpy of x86_nops, from Leon Hwang. 8) Follow-up for libbpf to support __arg_ctx global function argument tag semantics to complement the merged kernel side, from Andrii Nakryiko. 9) Introduce "volatile compare" macros for BPF selftests in order to make the latter more robust against compiler optimization, from Alexei Starovoitov. 10) Small simplification in verifier's size checking of helper accesses along with additional selftests, from Andrei Matei. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (40 commits) selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach bpf: Fix re-attachment branch in bpf_tracing_prog_attach selftests/bpf: Add test for recursive attachment of tracing progs bpf: Relax tracing prog recursive attach rules bpf, x86: Use emit_nops to replace memcpy x86_nops selftests/bpf: Test gotol with large offsets selftests/bpf: Double the size of test_loader log s390/bpf: Fix gotol with large offsets bpfilter: remove bpfilter bpf: Remove unnecessary cpu == 0 check in memalloc selftests/bpf: add __arg_ctx BTF rewrite test selftests/bpf: add arg:ctx cases to test_global_funcs tests libbpf: implement __arg_ctx fallback logic libbpf: move BTF loading step after relocation step libbpf: move exception callbacks assignment logic into relocation step libbpf: use stable map placeholder FDs libbpf: don't rely on map->fd as an indicator of map being created libbpf: use explicit map reuse flag to skip map creation steps libbpf: make uniform use of btf__fd() accessor inside libbpf selftests/bpf: Add a selftest with > 512-byte percpu allocation size ... ==================== Link: https://lore.kernel.org/r/20240105170105.21070-1-daniel@iogearbox.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vadim Fedorenko authored
The fb.com domain is going to be deprecated. Use personal one for kernel contributions. Signed-off-by:
Vadim Fedorenko <vadfed@fb.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240104172540.2379128-1-vadfed@meta.comSigned-off-by:
-
Eric Dumazet authored
geneve updates dev->stats fields locklessly. Adopt DEV_STATS_INC() to avoid races. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
-
- 05 Jan, 2024 36 commits
-
-
Jakub Kicinski authored
Richard Gobert says: ==================== net: gro: reduce extension header parsing overhead This series attempts to reduce the parsing overhead of IPv6 extension headers in GRO and GSO, by removing extension header specific code and enabling the frag0 fast path. The following changes were made: - Removed some unnecessary HBH conditionals by adding HBH offload to inet6_offloads - Added a utility function to support frag0 fast path in ipv6_gro_receive - Added selftests for IPv6 packets with extension headers in GRO v2: https://lore.kernel.org/netdev/127b8199-1cd4-42d7-9b2b-875abaad93fe@gmail.com/ v1: https://lore.kernel.org/netdev/f4eff69d-3917-4c42-8c6b-d09597ac4437@gmail.com/ ==================== Link: https://lore.kernel.org/r/ac6fb684-c00e-449c-92c3-99358a927ade@gmail.comSigned-off-by:
-
Richard Gobert authored
Currently there is no test which checks that IPv6 extension header packets successfully coalesce. This commit adds a test, which verifies two IPv6 packets with HBH extension headers do coalesce, and another test which checks that packets with different extension header data do not coalesce in GRO. I changed the receive socket filter to accept a packet with one extension header. This change exposed a bug in the fragment test -- the old BPF did not accept the fragment packet. I updated correct_num_packets in the fragment test accordingly. Signed-off-by:
Richard Gobert <richardbgobert@gmail.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/69282fed-2415-47e8-b3d3-34939ec3eb56@gmail.comSigned-off-by:
-
Richard Gobert authored
The existing code always pulls the IPv6 header and sets the transport offset initially. Then optionally again pulls any extension headers in ipv6_gso_pull_exthdrs and sets the transport offset again on return from that call. skb->data is set at the start of the first extension header before calling ipv6_gso_pull_exthdrs, and must disable the frag0 optimization because that function uses pskb_may_pull/pskb_pull instead of skb_gro_ helpers. It sets the GRO offset to the TCP header with skb_gro_pull and sets the transport header. Then returns skb->data to its position before this block. This commit introduces a new helper function - ipv6_gro_pull_exthdrs - which is used in ipv6_gro_receive to pull ipv6 ext headers instead of ipv6_gso_pull_exthdrs. Thus, there is no modification of skb->data, all operations use skb_gro_* helpers, and the frag0 fast path can be taken for IPv6 packets with ext headers. Signed-off-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
-
Richard Gobert authored
This commit adds net_offload to IPv6 Hop-by-Hop extension headers (as it is done for routing and dstopts) since it is supported in GSO and GRO. This allows to remove specific HBH conditionals in GSO and GRO when pulling and parsing an incoming packet. Signed-off-by:
-
Jakub Kicinski authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to all the CAIF sub-modules. Link: https://lore.kernel.org/r/20240104144855.1320993-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add description to net/packet/af_packet.c Acked-by:
-
Jakub Kicinski authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to all the DSA tag modules. The descriptions are copy/pasted Kconfig names, with s/^Tag/DSA tag/. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Acked-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by:
Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20240104143759.1318137-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to all the ATM modules and drivers. Link: https://lore.kernel.org/r/20240104143737.1317945-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Jiri Pirko says: ==================== dpll: expose fractional frequency offset value to user Allow to expose pin fractional frequency offset value over new DPLL generic netlink attribute. Add an op to get the value from the driver. Implement this new op in mlx5 driver. ==================== Link: https://lore.kernel.org/r/20240103132838.1501801-1-jiri@resnulli.usSigned-off-by:
-
Jiri Pirko authored
Implement ffo_get() pin op filling it up to MSEED.frequency_diff value. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Acked-by:
Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by:
-
Jiri Pirko authored
Instead of passing separate args, introduce struct mlx5_dpll_synce_status to hold the values obtained by mlx5_dpll_synce_status_get(). Signed-off-by:
-
Jiri Pirko authored
Add a new netlink attribute to expose fractional frequency offset value for a pin. Add an op to get the value from the driver. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== ds->user_mii_bus cleanup (part 1) There are some drivers which assign ds->user_mii_bus when they don't really need its specific functionality, aka non-OF based dsa_user_phy_connect(). There was some confusion regarding the fact that yes, this is why ds->user_mii_bus really exists, so I've started a cleanup series which aims to eliminate the usage of ds->user_mii_bus from drivers when there is nothing to gain from it. Today's drivers are lantiq_gswip, qca8k and bcm_sf2. The work is not done here, but a "part 2" may or may not come, depending on other priorities. All patches were only compile-tested. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
There used to be a of_node_put(priv->master_mii_dn) call in bcm_sf2_mdio_unregister(), which was accidentally deleted in commit 6ca80638 ("net: dsa: Use conduit and user terms"). But it's not needed - we don't need to hold a reference on the "brcm,unimac-mdio" OF node for that long, since we don't do anything with it. We can release it as soon as we finish bcm_sf2_mdio_register(). Also reduce "if (err && dn)" to just "if (err)". We know "dn", aka the former priv->master_mii_dn, is non-NULL. Otherwise, of_mdio_find_bus(dn) would not have been able to find the bus behind "brcm,unimac-mdio". Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
The bcm_sf2 driver does something strange. Instead of calling of_mdiobus_register() with an OF node argument, it manually assigns the bus->dev->of_node and then calls the non-OF mdiobus_register(). This circumvents some code from __of_mdiobus_register() from running, which sets the auto-scan mask, parses some device tree properties, etc. I'm going to go out on a limb and say that the OF node isn't, in fact, needed at all, and can be removed. The MDIO diversion as initially implemented in commit 461cd1b0 ("net: dsa: bcm_sf2: Register our slave MDIO bus") looked quite different than it is now, after commit 771089c2 ("net: dsa: bcm_sf2: Ensure that MDIO diversion is used"). Initially, it made sense, as bcm_sf2 was registering another set of driver ops for the "brcm,unimac-mdio" OF node. But now, it deletes all phandles, which makes "phy-handle"s unable to find PHYs, which means that it always goes through the OF-unaware dsa_user_phy_connect(). Signed-off-by:
-
Vladimir Oltean authored
Accessed either through priv->dev or ds->dev, it is the same device structure. Keep a single variable which holds a reference to it, and use it consistently. Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
-
Vladimir Oltean authored
__of_mdiobus_register() already calls __mdiobus_register() if the OF node provided as argument is NULL. We can take advantage of that and simplify the 2 code path, calling devm_of_mdiobus_register() only once for both cases. Signed-off-by:
-
Vladimir Oltean authored
To simplify reasoning about why the DSA framework provides the ds->user_mii_bus functionality, drivers should only use it if they need to. The qca8k driver appears to also use it simply as storage for a pointer, which is not a good enough reason to make the core much more difficult to follow. ds->user_mii_bus is useful for only 2 cases: 1. The driver probes on platform_data (no OF) 2. The driver probes on OF, but there is no OF node for the MDIO bus. It is unclear if case (1) is supported with qca8k. It might not be: the driver might crash when of_device_get_match_data() returns NULL and then it dereferences priv->info without NULL checking. Anyway, let us limit the ds->user_mii_bus usage only to the above cases, and not assign it when an OF node is present. The bus->phy_mask assignment follows along with the movement, because __of_mdiobus_register() overwrites this bus field anyway. The value set by the driver only matters for the non-OF code path. Signed-off-by:
-
Vladimir Oltean authored
Currently the driver calls the non-OF devm_mdiobus_register() rather than devm_of_mdiobus_register() for this case, but it seems to rather be a confusing coincidence, and not a real use case that needs to be supported. If the device tree says status = "disabled" for the MDIO bus, we shouldn't need an MDIO bus at all. Instead, just exit as early as possible and do not call any MDIO API. Signed-off-by:
-
Vladimir Oltean authored
of_get_child_by_name() gives us an OF node with an elevated refcount, which should be dropped when we're done with it. This is so that, if (of_node_check_flag(node, OF_DYNAMIC)) is true, the node's memory can eventually be freed. There are 2 distinct paths to be considered in qca8k_mdio_register(): - devm_of_mdiobus_register() succeeds: since commit 3b73a7b8 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), the MDIO core treats this well. - devm_of_mdiobus_register() or anything up to that point fails: it is the duty of the qca8k driver to release the OF node. This change addresses the second case by making sure that the OF node reference is not leaked. The "mdio" node may be NULL, but of_node_put(NULL) is safe. Signed-off-by:
-
Vladimir Oltean authored
If the "lantiq,xrx200-mdio" child has status = "disabled", the MDIO bus creation should be avoided. Use of_device_is_available() to check for that, and take advantage of 2 facts: - of_device_is_available(NULL) returns false - of_node_put(NULL) is a no-op Signed-off-by:
-
Vladimir Oltean authored
This driver does not need any of the functionalities that make ds->user_mii_bus special. Those use cases are listed here: https://lore.kernel.org/netdev/20231221174746.hylsmr3f7g5byrsi@skbuf/ It just makes use of ds->user_mii_bus only as storage for its own MDIO bus, which otherwise has no connection to the framework. This is because: - the gswip driver only probes on OF: it fails if of_device_get_match_data() returns NULL - when the child OF node of the MDIO bus is absent, no MDIO bus is registered at all, not even by the DSA framework. In order for that to have happened, the gswip driver would have needed to provide ->phy_read() and ->phy_write() in struct dsa_switch_ops, which it does not. We can break the connection between the gswip driver and the DSA framework and still preserve the same functionality. Since commit 3b73a7b8 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), MDIO buses take ownership of the OF node handled to them, and release it on their own. The gswip driver no longer needs to do this. Combine that with devres, and we no longer need to keep track of anything for teardown purposes. Signed-off-by:
-
Vladimir Oltean authored
__of_mdiobus_register(), called right next, overwrites the phy_mask we just configured on the bus, so this is redundant and confusing. Delete it. Signed-off-by:
-
Jiri Pirko authored
Inserting the device to block xarray in qdisc_create() is not suitable place to do this. As it requires use of tcf_block() callback, it causes multiple issues. It is called for all qdisc types, which is incorrect. So, instead, move it to more suitable place, which is tcf_block_get_ext() and make sure it is only done for qdiscs that use block infrastructure and also only for blocks which are shared. Symmetrically, alter the cleanup path, move the xarray entry removal into tcf_block_put_ext(). Fixes: 913b47d3 ("net/sched: Introduce tc block netdev tracking infra") Reported-by:
Ido Schimmel <idosch@nvidia.com> Closes: https://lore.kernel.org/all/ZY1hBb8GFwycfgvd@shredder/Reported-by:
Kui-Feng Lee <sinquersw@gmail.com> Closes: https://lore.kernel.org/all/ce8d3e55-b8bc-409c-ace9-5cf1c4f7c88e@gmail.com/ Reported-and-tested-by: syzbot+84339b9e7330daae4d66@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000007c85f5060dcc3a28@google.com/ Reported-and-tested-by: syzbot+806b0572c8d06b66b234@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/00000000000082f2f2060dcc3a92@google.com/ Reported-and-tested-by: syzbot+0039110f932d438130f9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000007fbc8c060dcc3a5c@google.com/Signed-off-by:
Victor Nogueira <victor@mojatatu.com> Tested-by:
Jamal Hadi Salim <jhs@mojatatu.com> Acked-by:
-
Alexei Starovoitov authored
Dmitrii Dolgov says: ==================== Relax tracing prog recursive attach rules Currently, it's not allowed to attach an fentry/fexit prog to another fentry/fexit. At the same time it's not uncommon to see a tracing program with lots of logic in use, and the attachment limitation prevents usage of fentry/fexit for performance analysis (e.g. with "bpftool prog profile" command) in this case. An example could be falcosecurity libs project that uses tp_btf tracing programs for offloading certain part of logic into tail-called programs, but the use-case is still generic enough -- a tracing program could be complicated and heavy enough to warrant its profiling, yet frustratingly it's not possible to do so use best tooling for that. Following the corresponding discussion [1], the reason for that is to avoid tracing progs call cycles without introducing more complex solutions. But currently it seems impossible to load and attach tracing programs in a way that will form such a cycle. Replace "no same type" requirement with verification that no more than one level of attachment nesting is allowed. In this way only one fentry/fexit program could be attached to another fentry/fexit to cover profiling use case, and still no cycle could be formed. The series contains a test for recursive attachment, as well as a fix + test for an issue in re-attachment branch of bpf_tracing_prog_attach. When preparing the test for the main change set, I've stumbled upon the possibility to construct a sequence of events when attach_btf would be NULL while computing a trampoline key. It doesn't look like this issue is triggered by the main change, because the reproduces doesn't actually need to have an fentry attachment chain. [1]: https://lore.kernel.org/bpf/20191108064039.2041889-16-ast@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240103190559.14750-1-9erthalion6@gmail.comSigned-off-by:
Alexei Starovoitov <ast@kernel.org>
-
Dmitrii Dolgov authored
Add a test case to verify the fix for "prog->aux->dst_trampoline and tgt_prog is NULL" branch in bpf_tracing_prog_attach. The sequence of events: 1. load rawtp program 2. load fentry program with rawtp as target_fd 3. create tracing link for fentry program with target_fd = 0 4. repeat 3 Acked-by:
Jiri Olsa <olsajiri@gmail.com> Acked-by:
Song Liu <song@kernel.org> Signed-off-by:
Dmitrii Dolgov <9erthalion6@gmail.com> Link: https://lore.kernel.org/r/20240103190559.14750-5-9erthalion6@gmail.comSigned-off-by:
-
Jiri Olsa authored
The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. Fixes: f3a95075 ("bpf: Allow trampoline re-attach for tracing and lsm programs") Cc: stable@vger.kernel.org Signed-off-by: -
Dmitrii Dolgov authored
Verify the fact that only one fentry prog could be attached to another fentry, building up an attachment chain of limited size. Use existing bpf_testmod as a start of the chain. Acked-by:
-
Dmitrii Dolgov authored
Currently, it's not allowed to attach an fentry/fexit prog to another one fentry/fexit. At the same time it's not uncommon to see a tracing program with lots of logic in use, and the attachment limitation prevents usage of fentry/fexit for performance analysis (e.g. with "bpftool prog profile" command) in this case. An example could be falcosecurity libs project that uses tp_btf tracing programs. Following the corresponding discussion [1], the reason for that is to avoid tracing progs call cycles without introducing more complex solutions. But currently it seems impossible to load and attach tracing programs in a way that will form such a cycle. The limitation is coming from the fact that attach_prog_fd is specified at the prog load (thus making it impossible to attach to a program loaded after it in this way), as well as tracing progs not implementing link_detach. Replace "no same type" requirement with verification that no more than one level of attachment nesting is allowed. In this way only one fentry/fexit program could be attached to another fentry/fexit to cover profiling use case, and still no cycle could be formed. To implement, add a new field into bpf_prog_aux to track nested attachment for tracing programs. [1]: https://lore.kernel.org/bpf/20191108064039.2041889-16-ast@kernel.org/Acked-by:
-
Leon Hwang authored
Move emit_nops() before emit_prologue() and replace memcpy(prog, x86_nops[5], X86_PATCH_SIZE) with emit_nops(&prog, X86_PATCH_SIZE). Signed-off-by:
Leon Hwang <hffilwlqm@gmail.com> Link: https://lore.kernel.org/r/20240104142226.87869-2-hffilwlqm@gmail.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/ethernet/broadcom/bnxt/bnxt.c e009b2ef ("bnxt_en: Remove mis-applied code from bnxt_cfg_ntp_filters()") 0f2b2147 ("bnxt_en: Fix compile error without CONFIG_RFS_ACCEL") https://lore.kernel.org/all/20240105115509.225aa8a2@canb.auug.org.au/Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2024-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Just a couple of more things over the holidays: - first kunit tests for both cfg80211 and mac80211 - a few multi-link fixes - DSCP mapping update - RCU fix * tag 'wireless-next-2024-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: wifi: mac80211: remove redundant ML element check wifi: cfg80211: parse all ML elements in an ML probe response wifi: cfg80211: correct comment about MLD ID wifi: cfg80211: Update the default DSCP-to-UP mapping wifi: cfg80211: tests: add some scanning related tests wifi: mac80211: kunit: extend MFP tests wifi: mac80211: kunit: generalize public action test wifi: mac80211: add kunit tests for public action handling kunit: add a convenience allocation wrapper for SKBs kunit: add parameter generation macro using description from array wifi: mac80211: fix spelling typo in comment wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update ==================== Link: https://lore.kernel.org/r/20240103144423.52269-3-johannes@sipsolutions.netSigned-off-by:
-
Heiner Kallweit authored
When r8169 is built-in but LED support is a loadable module, the new code to drive the LED causes a link failure: ld: drivers/net/ethernet/realtek/r8169_leds.o: in function `rtl8168_init_leds': r8169_leds.c:(.text+0x36c): undefined reference to `devm_led_classdev_register_ext' LED support is an optional feature, so fix this issue by adding a Kconfig symbol R8169_LEDS that is guaranteed to be false if r8169 is built-in and LED core support is a module. As a positive side effect of this change r8169_leds.o no longer is built under this configuration. Fixes: 18764b88 ("r8169: add support for LED's on RTL8168/RTL8101") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312281159.9TPeXbNd-lkp@intel.com/Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
Vladimir Oltean authored
The driver code proper is handled by the lynx_pcs. The enetc just needs to populate phylink's supported_interfaces array, and return true for this phy-mode in enetc_port_has_pcs(), such that it creates an internal MDIO bus through which the Lynx PCS registers are accessed. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from Jakub Kicinski: "Including fixes from wireless and netfilter. We haven't accumulated much over the break. If it wasn't for the uninterrupted stream of fixes for Intel drivers this PR would be very slim. There was a handful of user reports, however, either they stood out because of the lower traffic or users have had more time to test over the break. The ones which are v6.7-relevant should be wrapped up. Current release - regressions: - Revert "net: ipv6/addrconf: clamp preferred_lft to the minimum required", it caused issues on networks where routers send prefixes with preferred_lft=0 - wifi: - iwlwifi: pcie: don't synchronize IRQs from IRQ, prevent deadlock - mac80211: fix re-adding debugfs entries during reconfiguration Current release - new code bugs: - tcp: print AO/MD5 messages only if there are any keys Previous releases - regressions: - virtio_net: fix missing dma unmap for resize, prevent OOM Previous releases - always broken: - mptcp: prevent tcp diag from closing listener subflows - nf_tables: - set transport header offset for egress hook, fix IPv4 mangling - skip set commit for deleted/destroyed sets, avoid double deactivation - nat: make sure action is set for all ct states, fix openvswitch matching on ICMP packets in related state - eth: mlxbf_gige: fix receive hang under heavy traffic - eth: r8169: fix PCI error on system resume for RTL8168FP - net: add missing getsockopt(SO_TIMESTAMPING_NEW) and cmsg handling" * tag 'net-6.7-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (52 commits) net/tcp: Only produce AO/MD5 logs if there are any keys net: Implement missing SO_TIMESTAMPING_NEW cmsg support bnxt_en: Remove mis-applied code from bnxt_cfg_ntp_filters() net: ravb: Wait for operating mode to be applied asix: Add check for usbnet_get_endpoints octeontx2-af: Re-enable MAC TX in otx2_stop processing octeontx2-af: Always configure NIX TX link credits based on max frame size net/smc: fix invalid link access in dumping SMC-R connections net/qla3xxx: fix potential memleak in ql_alloc_buffer_queues virtio_net: fix missing dma unmap for resize igc: Fix hicredit calculation ice: fix Get link status data length i40e: Restore VF MSI-X state during PCI reset i40e: fix use-after-free in i40e_aqc_add_filters() net: Save and restore msg_namelen in sock_sendmsg netfilter: nft_immediate: drop chain reference counter on error netfilter: nf_nat: fix action not being set for all ct states net: bcmgenet: Fix FCS generation for fragmented skbuffs mptcp: prevent tcp diag from closing listener subflows MAINTAINERS: add Geliang as reviewer for MPTCP ... -
Jakub Kicinski authored
This reverts commit 32bb4515. This reverts commit d078d480. This reverts commit fcc4b105. This reverts commit 345237db. This reverts commit 7db69ec9. This reverts commit 95132a01. This reverts commit 63d5eaf3. This reverts commit c29451ae. This reverts commit 2ab0edb5. This reverts commit dedd702a. This reverts commit 034fcc21. This reverts commit 9c5625f5. This reverts commit 02018c54. Looks like we need more time for reviews, and incremental changes will be hard to make sense of. So revert. Link: https://lore.kernel.org/all/ZZP6FV5sXEf+xd58@shell.armlinux.org.uk/Signed-off-by:
-
- 04 Jan, 2024 1 commit
-
-
Linus Torvalds authored
Commit 688eb819 ("x86/csum: Improve performance of `csum_partial`") ended up improving the code generation for the IP csum calculations, and in particular special-casing the 40-byte case that is a hot case for IPv6 headers. It then had _another_ special case for the 64-byte unrolled loop, which did two chains of 32-byte blocks, which allows modern CPU's to improve performance by doing the chains in parallel thanks to renaming the carry flag. This just unifies the special cases and combines them into just one single helper the 40-byte csum case, and replaces the 64-byte case by a 80-byte case that just does that single helper twice. It avoids having all these different versions of inline assembly, and actually improved performance further in my tests. There was never anything magical about the 64-byte unrolled case, even though it happens to be a common size (and typically is the cacheline size). Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
