- 06 Jan, 2022 4 commits
-
-
Ong Boon Leong authored
To set Dest MAC address (-G|--tx-dmac) only: $ xdpsock -i eth0 -t -N -z -G aa:bb:cc:dd:ee:ff To set Source MAC address (-H|--tx-smac) only: $ xdpsock -i eth0 -t -N -z -H 11:22:33:44:55:66 To set both Dest and Source MAC address: $ xdpsock -i eth0 -t -N -z -G aa:bb:cc:dd:ee:ff \ -H 11:22:33:44:55:66 The default Dest and Source MAC address remain the same as before. Signed-off-by:
Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/bpf/20211230035447.523177-3-boon.leong.ong@intel.com
-
Ong Boon Leong authored
In multi-queue environment testing, the support for VLAN-tag based steering is useful. So, this patch adds the capability to add VLAN tag (VLAN ID and Priority) to the generated Tx frame. To set the VLAN ID=10 and Priority=2 for Tx only through TxQ=3: $ xdpsock -i eth0 -t -N -z -q 3 -V -J 10 -K 2 If VLAN ID (-J) and Priority (-K) is set, it default to VLAN ID = 1 VLAN Priority = 0. For example, VLAN-tagged Tx only, xdp copy mode through TxQ=1: $ xdpsock -i eth0 -t -N -c -q 1 -V Signed-off-by:
-
Christy Lee authored
API created with simplistic assumptions about BPF map definitions. It hasn’t worked for a while, deprecate it in preparation for libbpf 1.0. [0] Closes: https://github.com/libbpf/libbpf/issues/302Signed-off-by:
Christy Lee <christylee@fb.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220105003120.2222673-1-christylee@fb.com
-
Christy Lee authored
Deprecate bpf_map__is_offload_neutral(). It’s most probably broken already. PERF_EVENT_ARRAY isn’t the only map that’s not suitable for hardware offloading. Applications can directly check map type instead. [0] Closes: https://github.com/libbpf/libbpf/issues/306Signed-off-by:
-
- 05 Jan, 2022 30 commits
-
-
Qiang Wang authored
If repeated legacy kprobes on same function in one process, libbpf will register using the same probe name and got -EBUSY error. So append index to the probe name format to fix this problem. Co-developed-by:
Chengming Zhou <zhouchengming@bytedance.com> Signed-off-by:
Qiang Wang <wangqiang.wq.frank@bytedance.com> Signed-off-by:
-
Qiang Wang authored
Fix a bug in commit 46ed5fc3, which wrongly used the func_name instead of probe_name to register legacy kprobe. Fixes: 46ed5fc3 ("libbpf: Refactor and simplify legacy kprobe code") Co-developed-by:
Hengqi Chen <hengqi.chen@gmail.com> Reviewed-by:
-
Christy Lee authored
With perf_buffer__poll() and perf_buffer__consume() APIs available, there is no reason to expose bpf_perf_event_read_simple() API to users. If users need custom perf buffer, they could re-implement the function. Mark bpf_perf_event_read_simple() and move the logic to a new static function so it can still be called by other functions in the same file. [0] Closes: https://github.com/libbpf/libbpf/issues/310Signed-off-by:
-
Kuniyuki Iwashima authored
This patch exposes SO_RCVBUF/SO_SNDBUF through bpf_getsockopt(). Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Signed-off-by:
-
Kuniyuki Iwashima authored
The commit 4057765f ("sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values") added a change to prevent underflow in setsockopt() around SO_SNDBUF/SO_RCVBUF. This patch adds the same change to _bpf_setsockopt(). Fixes: 4057765f ("sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values") Signed-off-by:
-
Kris Van Hees authored
Commit bfc6bb74 ("bpf: Implement verifier support for validation of async callbacks.") added support for BPF_FUNC_timer_set_callback to the __check_func_call() function. The test in __check_func_call() is flaweed because it can mis-interpret a regular BPF-to-BPF pseudo-call as a BPF_FUNC_timer_set_callback callback call. Consider the conditional in the code: if (insn->code == (BPF_JMP | BPF_CALL) && insn->imm == BPF_FUNC_timer_set_callback) { The BPF_FUNC_timer_set_callback has value 170. This means that if you have a BPF program that contains a pseudo-call with an instruction delta of 170, this conditional will be found to be true by the verifier, and it will interpret the pseudo-call as a callback. This leads to a mess with the verification of the program because it makes the wrong assumptions about the nature of this call. Solution: include an explicit check to ensure that insn->src_reg == 0. This ensures that calls cannot be mis-interpreted as an async callback call. Fixes: bfc6bb74 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by:
Kris Van Hees <kris.van.hees@oracle.com> Signed-off-by:
-
Christoph Hellwig authored
Add a description for all the modifiers. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Add pseudo-code to document all the different BPF_JMP / BPF_JMP64 opcodes. Signed-off-by:
-
Christoph Hellwig authored
Add pseudo-code to document all the different BPF_ALU / BPF_ALU64 opcodes. Signed-off-by:
-
Christoph Hellwig authored
Add a description for each opcode class. Signed-off-by:
-
Christoph Hellwig authored
Add a little more stucture to the ALU/JMP documentation with sections and improve the example text. Signed-off-by:
-
Christoph Hellwig authored
The eBPF instruction set document does not currently document the basic instruction encoding. Add a section to do that. Signed-off-by:
-
Daniel Borkmann authored
Add a new test case with mem_or_null typed register with off > 0 to ensure it gets rejected by the verifier: # ./test_verifier 1011 #1009/u check with invalid reg offset 0 OK #1009/p check with invalid reg offset 0 OK Summary: 2 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Daniel Borkmann authored
If we ever get to a point again where we convert a bogus looking <ptr>_or_null typed register containing a non-zero fixed or variable offset, then lets not reset these bounds to zero since they are not and also don't promote the register to a <ptr> type, but instead leave it as <ptr>_or_null. Converting to a unknown register could be an avenue as well, but then if we run into this case it would allow to leak a kernel pointer this way. Fixes: f1174f77 ("bpf/verifier: rework value tracking") Signed-off-by:
-
John Fastabend authored
sock_map_link() is called to update a sockmap entry with a sk. But, if the sock_map_init_proto() call fails then we return an error to the map_update op against the sockmap. In the error path though we need to cleanup psock and dec the refcnt on any programs associated with the map, because we refcnt them early in the update process to ensure they are pinned for the psock. (This avoids a race where user deletes programs while also updating the map with new socks.) In current code we do the prog refcnt dec explicitely by calling bpf_prog_put() when the program was found in the map. But, after commit '38207a5e' in this error path we've already done the prog to psock assignment so the programs have a reference from the psock as well. This then causes the psock tear down logic, invoked by sk_psock_put() in the error path, to similarly call bpf_prog_put on the programs there. To be explicit this logic does the prog->psock assignment: if (msg_*) psock_set_prog(...) Then the error path under the out_progs label does a similar check and dec with: if (msg_*) bpf_prog_put(...) And the teardown logic sk_psock_put() does ... psock_set_prog(msg_*, NULL) ... triggering another bpf_prog_put(...). Then KASAN gives us this splat, found by syzbot because we've created an inbalance between bpf_prog_inc and bpf_prog_put calling put twice on the program. BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put kernel/bpf/syscall.c:1812 [inline] BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put kernel/bpf/syscall.c:1812 [inline] kernel/bpf/syscall.c:1829 BUG: KASAN: vmalloc-out-of-bounds in bpf_prog_put+0x8c/0x4f0 kernel/bpf/syscall.c:1829 kernel/bpf/syscall.c:1829 Read of size 8 at addr ffffc90000e76038 by task syz-executor020/3641 To fix clean up error path so it doesn't try to do the bpf_prog_put in the error path once progs are assigned then it relies on the normal psock tear down logic to do complete cleanup. For completness we also cover the case whereh sk_psock_init_strp() fails, but this is not expected because it indicates an incorrect socket type and should be caught earlier. Fixes: 38207a5e ("bpf, sockmap: Attach map progs to psock early for feature probes") Reported-by: syzbot+bb73e71cf4b8fd376a4f@syzkaller.appspotmail.com Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
John Fastabend authored
Applications can be confused slightly because we do not always return the same error code as expected, e.g. what the TCP stack normally returns. For example on a sock err sk->sk_err instead of returning the sock_error we return EAGAIN. This usually means the application will 'try again' instead of aborting immediately. Another example, when a shutdown event is received we should immediately abort instead of waiting for data when the user provides a timeout. These tend to not be fatal, applications usually recover, but introduces bogus errors to the user or introduces unexpected latency. Before 'c5d2177a' we fell back to the TCP stack when no data was available so we managed to catch many of the cases here, although with the extra latency cost of calling tcp_msg_wait_data() first. To fix lets duplicate the error handling in TCP stack into tcp_bpf so that we get the same error codes. These were found in our CI tests that run applications against sockmap and do longer lived testing, at least compared to test_sockmap that does short-lived ping/pong tests, and in some of our test clusters we deploy. Its non-trivial to do these in a shorter form CI tests that would be appropriate for BPF selftests, but we are looking into it so we can ensure this keeps working going forward. As a preview one idea is to pull in the packetdrill testing which catches some of this. Fixes: c5d2177a ("bpf, sockmap: Fix race in ingress receive verdict with redirect to self") Signed-off-by:
-
Hou Tao authored
The following error is reported when running "./test_progs -t for_each" under arm64: bpf_jit: multi-func JIT bug 58 != 56 [...] JIT doesn't support bpf-to-bpf calls The root cause is the size of BPF_PSEUDO_FUNC instruction increases from 2 to 3 after the address of called bpf-function is settled and there are two bpf-to-bpf calls in test_pkt_access. The generated instructions are shown below: 0x48: 21 00 C0 D2 movz x1, #0x1, lsl #32 0x4c: 21 00 80 F2 movk x1, #0x1 0x48: E1 3F C0 92 movn x1, #0x1ff, lsl #32 0x4c: 41 FE A2 F2 movk x1, #0x17f2, lsl #16 0x50: 81 70 9F F2 movk x1, #0xfb84 Fixing it by using emit_addr_mov_i64() for BPF_PSEUDO_FUNC, so the size of jited image will not change. Fixes: 69c087ba ("bpf: Add bpf_for_each_map_elem() helper") Signed-off-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
-
Jiri Olsa authored
The tc_redirect umounts /sys in the new namespace, which can be mounted as shared and cause global umount. The lazy umount also takes down mounted trees under /sys like debugfs, which won't be available after sysfs mounts again and could cause fails in other tests. # cat /proc/self/mountinfo | grep debugfs 34 23 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:14 - debugfs debugfs rw # cat /proc/self/mountinfo | grep sysfs 23 86 0:22 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw # mount | grep debugfs debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) # ./test_progs -t tc_redirect #164 tc_redirect:OK Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED # mount | grep debugfs # cat /proc/self/mountinfo | grep debugfs # cat /proc/self/mountinfo | grep sysfs 25 86 0:22 / /sys rw,relatime shared:2 - sysfs sysfs rw Making the sysfs private under the new namespace so the umount won't trigger the global sysfs umount. Reported-by:
Hangbin Liu <haliu@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
-
Paul Chaignon authored
This patch introduces new probes to check whether the kernel supports instruction set extensions v2 and v3. The first introduced eBPF instructions BPF_J{LT,LE,SLT,SLE} in commit 92b31a9a ("bpf: add BPF_J{LT,LE,SLT,SLE} instructions"). The second introduces 32-bit variants of all jump instructions in commit 092ed096 ("bpf: verifier support JMP32"). These probes are useful for userspace BPF projects that want to use newer instruction set extensions on newer kernels, to reduce the programs' sizes or their complexity. LLVM already provides an mcpu=probe option to automatically probe the kernel and select the newest-supported instruction set extension. That is however not flexible enough for all use cases. For example, in Cilium, we only want to use the v3 instruction set extension on v5.10+, even though it is supported on all kernels v5.1+. Signed-off-by:Paul Chaignon <paul@isovalent.com> Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/3bfedcd9898c1f41ac67ca61f144fec84c6c3a92.1641314075.git.paul@isovalent.com
-
Paul Chaignon authored
This patch introduces a new probe to check whether the verifier supports bounded loops as introduced in commit 2589726d ("bpf: introduce bounded loops"). This patch will allow BPF users such as Cilium to probe for loop support on startup and only unconditionally unroll loops on older kernels. The results are displayed as part of the miscellaneous section, as shown below. $ bpftool feature probe | grep loops Bounded loop support is available $ bpftool feature probe macro | grep LOOPS #define HAVE_BOUNDED_LOOPS $ bpftool feature probe -j | jq .misc { "have_large_insn_limit": true, "have_bounded_loops": true } Signed-off-by:
-
Paul Chaignon authored
There is currently a single miscellaneous feature probe, HAVE_LARGE_INSN_LIMIT, to check for the 1M instructions limit in the verifier. Subsequent patches will add additional miscellaneous probes, which follow the same pattern at the existing probe. This patch therefore refactors the probe to avoid code duplication in subsequent patches. The BPF program type and the checked error numbers in the HAVE_LARGE_INSN_LIMIT probe are changed to better generalize to other probes. The feature probe retains its current behavior despite those changes. Signed-off-by:
-
David S. Miller authored
Horatiu Vultur says: ==================== net: lan966x: Extend switchdev with mdb support This patch series extends lan966x with mdb support by implementing the switchdev callbacks: SWITCHDEV_OBJ_ID_PORT_MDB and SWITCHDEV_OBJ_ID_HOST_MDB. It adds support for both ipv4/ipv6 entries and l2 entries. v2->v3: - rename PGID_FIRST and PGID_LAST to PGID_GP_START and PGID_GP_END - don't forget and relearn an entry for the CPU if there are more references to the cpu. v1->v2: - rename lan966x_mac_learn_impl to __lan966x_mac_learn - rename lan966x_mac_cpu_copy to lan966x_mac_ip_learn - fix grammar and typos in comments and commit messages - add reference counter for entries that copy frames to CPU ==================== Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Extend lan966x driver with mdb support by implementing the switchdev calls: SWITCHDEV_OBJ_ID_PORT_MDB and SWITCHDEV_OBJ_ID_HOST_MDB. It is allowed to add both ipv4/ipv6 entries and l2 entries. To add ipv4/ipv6 entries is not required to use the PGID table while for l2 entries it is required. The PGID table is much smaller than MAC table so only fewer l2 entries can be added. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
The first entries in the PGID table are used by the front ports while the last entries are used for different purposes like flooding mask, copy to CPU, etc. So add these macros to define which entries can be used for general purpose. Signed-off-by:
-
Horatiu Vultur authored
Extend mac functionality with the function lan966x_mac_ip_learn. This function adds an entry in the MAC table for IP multicast addresses. These entries can copy a frame to the CPU but also can forward on the front ports. This functionality is needed for mdb support. In case the CPU and some of the front ports subscribe to an IP multicast address. Signed-off-by:
-
David S. Miller authored
Daniel Golle says: ==================== net: ethernet: mtk_eth_soc: refactoring and Clause 45 Rework value and type of mdio read and write functions in mtk_eth_soc and generally clean up and unify both functions. Then add support to access Clause 45 phy registers, using newly introduced helper inline functions added by a patch Russell King has suggested in a reply to an earlier version of this series [1]. All three commits are tested on the Bananapi BPi-R64 board having MediaTek MT7531BE DSA gigE switch using clause 22 MDIO and Ubiquiti UniFi 6 LR access point having Aquantia AQR112C PHY using clause 45 MDIO. [1]: https://lore.kernel.org/netdev/Ycr5Cna76eg2B0An@shell.armlinux.org.uk/ v11: also address return value of mtk_mdio_busy_wait v10: correct order of SoB lines in 2/3, change patch order in series v9: improved formatting and Cc missing maintainer v8: add patch from Russel King, switch to bitfield helper macros v7: remove unneeded variables and order OR-ed call parameters v6: further clean up functions and more cleanly separate patches v5: fix wrong variable name in first patch covered by follow-up patch v4: clean-up return values and types, split into two commits v3: return -1 instead of 0xffff on error in _mtk_mdio_write v2: use MII_DEVADDR_C45_SHIFT and MII_REGADDR_C45_MASK to extract device id and register address. Unify read and write functions to have identical types and parameter names where possible as we are anyway already replacing both function bodies. ==================== Signed-off-by:
-
Daniel Golle authored
Implement read and write access to IEEE 802.3 Clause 45 Ethernet phy registers while making use of new mdiobus_c45_regad and mdiobus_c45_devad helpers. Tested on the Ubiquiti UniFi 6 LR access point featuring MediaTek MT7622BV WiSoC with Aquantia AQR112C. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
-
Russell King (Oracle) authored
Add a couple of helpers and definitions to extract the clause 45 regad and devad fields from the regnum passed into MDIO drivers. Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Daniel Golle authored
Instead of returning -1 (-EPERM) when MDIO bus is stuck busy while writing or 0xffff if it happens while reading, return the appropriate -ETIMEDOUT. Also fix return type to int instead of u32. Refactor functions to use bitfield helpers instead of having various masking and shifting constants in the code, which also results in the register definitions in the header file being more obviously related to what is stated in the MediaTek's Reference Manual. Fixes: 656e7052 ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by:
-
M Chetan Kumar authored
Depending on BIOS configuration IOSM driver exchanges protocol required for putting device into D3L2 or D3L1.2. ipc_pcie_suspend_s2idle() is implemented to put device to D3L1.2. This patch forces PCI core know this device should stay at D0. - pci_save_state()is expensive since it does a lot of slow PCI config reads. The reported issue is not observed on x86 platform. The supurios wake on AMD platform needs to be futher debugged with orignal patch submitter [1]. Also the impact of adding pci_save_state() needs to be assessed by testing it on other platforms. This reverts commit f4dd5174("net: wwan: iosm: Keep device at D0 for s2idle case"). [1] https://lore.kernel.org/all/20211224081914.345292-2-kai.heng.feng@canonical.com/Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Link: https://lore.kernel.org/r/20220104150213.1894-1-m.chetan.kumar@linux.intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 04 Jan, 2022 6 commits
-
-
Jakub Kicinski authored
Merge tag 'mac80211-next-for-net-next-2022-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Just a few more changes: - mac80211: allow non-standard VHT MCSes 10/11 - mac80211: add sleepable station iterator for drivers - nl80211: clarify a comment - mac80211: small cleanup to use typed element helpers * tag 'mac80211-next-for-net-next-2022-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: mac80211: use ieee80211_bss_get_elem() nl80211: clarify comment for mesh PLINK_BLOCKED state mac80211: Add stations iterator where the iterator function may sleep mac80211: allow non-standard VHT MCS-10/11 ==================== Link: https://lore.kernel.org/r/20220104153403.69749-1-johannes@sipsolutions.netSigned-off-by:
-
Johannes Berg authored
Instead of ieee80211_bss_get_ie(), use the more typed ieee80211_bss_get_elem(). Link: https://lore.kernel.org/r/20211220113609.56f8e2a70152.Id5a56afb8a4f9b38d10445e5a1874e93e84b5251@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Felix Fietkau authored
When a mesh link is in blocked state, it is very useful to still allow auth requests from the peer to re-establish it. When a remote node is power cycled, the peer state can easily end up in blocked state if multiple auth attempts are performed. Since this can lead to several minutes of downtime, we should accept auth attempts of the peer after it has come back. Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20211220105147.88625-1-nbd@nbd.nameSigned-off-by:
-
Martin Blumenstingl authored
ieee80211_iterate_active_interfaces() and ieee80211_iterate_active_interfaces_atomic() already exist, where the former allows the iterator function to sleep. Add ieee80211_iterate_stations() which is similar to ieee80211_iterate_stations_atomic() but allows the iterator to sleep. This is needed for adding SDIO support to the rtw88 driver. Some interators there are reading or writing registers. With the SDIO ops (sdio_readb, sdio_writeb and friends) this means that the iterator function may sleep. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20211228211501.468981-2-martin.blumenstingl@googlemail.comSigned-off-by:
-
Ping-Ke Shih authored
Some AP can possibly try non-standard VHT rate and mac80211 warns and drops packets, and leads low TCP throughput. Rate marked as a VHT rate but data is invalid: MCS: 10, NSS: 2 WARNING: CPU: 1 PID: 7817 at net/mac80211/rx.c:4856 ieee80211_rx_list+0x223/0x2f0 [mac8021 Since commit c27aa56a ("cfg80211: add VHT rate entries for MCS-10 and MCS-11") has added, mac80211 adds this support as well. After this patch, throughput is good and iw can get the bitrate: rx bitrate: 975.1 MBit/s VHT-MCS 10 80MHz short GI VHT-NSS 2 or rx bitrate: 1083.3 MBit/s VHT-MCS 11 80MHz short GI VHT-NSS 2 Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1192891Reported-by:Goldwyn Rodrigues <rgoldwyn@suse.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/20220103013623.17052-1-pkshih@realtek.comSigned-off-by:
-
Minghao Chi authored
Return value from efx_mcdi_rpc() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
CGEL ZTE <cgel.zte@gmail.com> Signed-off-by:
-
