Bpf test config #9360
Open
Bpf test config #9360
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # net/core/neighbour.c
Ethtool has advanced with additional configurable options, but the current driver does not support tx-usecs configuration. Add support to configure and retrieve 'tx-usecs' using ethtool, which specifies the wait time before servicing an interrupt for Tx coalescing. Signed-off-by: Vishal Badole <[email protected]> Acked-by: Shyam Sundar S K <[email protected]> Signed-off-by: NipaLocal <nipa@local>
A negative overflow can happen when the budget number of descs are consumed. as long as the budget is decreased to zero, it will again go into while (budget-- > 0) statement and get decreased by one, so the overflow issue can happen. It will lead to returning true whereas the expected value should be false. In this case where all the budget is used up, it means zc function should return false to let the poll run again because normally we might have more data to process. Without this patch, zc function would return true instead. Fixes: 132c32e ("net: stmmac: Add TX via XDP zero-copy socket") Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Signed-off-by: NipaLocal <nipa@local>
There is no break time in the while() loop, so every time at the end of igb_xmit_zc(), negative overflow of nb_pkts will occur, which renders the return value always false. But theoretically, the result should be set after calling xsk_tx_peek_release_desc_batch(). We can take i40e_xmit_zc() as a good example. Returning false means we're not done with transmission and we need one more poll, which is exactly what igb_xmit_zc() always did before this patch. After this patch, the return value depends on the nb_pkts value. Two cases might happen then: 1. if (nb_pkts < budget), it means we process all the possible data, so return true and no more necessary poll will be triggered because of this. 2. if (nb_pkts == budget), it means we might have more data, so return false to let another poll run again. Fixes: f8e284a ("igb: Add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Emails to [email protected] bounce permanently: Remote Server returned '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup' so replace him with Marcelo Schmitt from Analog. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Convert at86rf230.txt yaml format. Additional changes: - Add ref to spi-peripheral-props.yaml. - Add parent spi node in examples. Reviewed-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The local variable 'vm_addr' is always not NULL, no need to check it. Signed-off-by: Wang Liang <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The esp4_offload module, loaded during IPsec offload tests, should be reset to its default settings after testing. Otherwise, leaving it enabled could unintentionally affect subsequence test cases by keeping offload active. Without this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload esp4_offload 12288 0 esp4 32768 1 esp4_offload With this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload Fixes: 2766a11 ("selftests: rtnetlink: add ipsec offload API test") Signed-off-by: Xiumei Mu <[email protected]> Reviewed-by: Shannon Nelson <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Silence deferred probes using dev_err_probe(). This can happen when the ethernet PHY uses an IRQ line attached to a i2c GPIO expander. If the i2c bus is not yet ready, a probe deferral can occur. Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Octeontx2/CN10K silicon supports generating a 256-bit key per packet. The specific fields to be extracted from a packet for key generation are configurable via a Key Extraction (MKEX) Profile. The AF driver scans the configured extraction profile to ensure that fields from upper layers do not overwrite fields from lower layers in the key. Example Packet Field Layout: LA: DMAC + SMAC LB: VLAN LC: IPv4/IPv6 LD: TCP/UDP Valid MKEX Profile Configuration: LA -> DMAC -> key_offset[0-5] LC -> SIP -> key_offset[20-23] LD -> SPORT -> key_offset[30-31] Invalid MKEX profile configuration: LA -> DMAC -> key_offset[0-5] LC -> SIP -> key_offset[20-23] LD -> SPORT -> key_offset[2-3] // Overlaps with DMAC field In another scenario, if the MKEX profile is configured to extract the SPI field from both AH and ESP headers at the same key offset, the driver rejecting this configuration. In a regular traffic, ipsec packet will be having either AF(LD) or ESP (LE). This patch relaxes the check for the same. Fixes: 12aa0a3 ("octeontx2-af: Harden rule validation.") Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Both taprio and mqprio have code to validate respective entry index attributes. The validation is indented to ensure that the attribute is present, and that it's value is in range, and that each value is only used once. The purpose of this patch is to align the implementation of taprio with that of mqprio as there seems to be no good reason for them to differ. For one thing, this way, bugs will be present in both or neither. As a follow-up some consideration could be given to a common function used by both sch. No functional change intended. Except of tdc run: the results of the taprio tests # ok 81 ba39 - Add taprio Qdisc to multi-queue device (8 queues) # ok 82 9462 - Add taprio Qdisc with multiple sched-entry # ok 83 8d92 - Add taprio Qdisc with txtime-delay # ok 84 d092 - Delete taprio Qdisc with valid handle # ok 85 8471 - Show taprio class # ok 86 0a85 - Add taprio Qdisc to single-queue device # ok 87 6f62 - Add taprio Qdisc with too short interval # ok 88 831f - Add taprio Qdisc with too short cycle-time # ok 89 3e1e - Add taprio Qdisc with an invalid cycle-time # ok 90 39b4 - Reject grafting taprio as child qdisc of software taprio # ok 91 e8a1 - Reject grafting taprio as child qdisc of offloaded taprio # ok 92 a7bf - Graft cbs as child of software taprio # ok 93 6a83 - Graft cbs as child of offloaded taprio Cc: Vladimir Oltean <[email protected]> Cc: Maher Azzouzi <[email protected]> Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Simon Horman <[email protected]> Reviewed-by: Cong Wang <[email protected]> Acked-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Flags passed in for splice() syscall should not end up in skb_recv_datagram(). As SPLICE_F_NONBLOCK == MSG_PEEK, kernel gets confused: skb isn't unlinked from a receive queue, while strp_msg::offset and strp_msg::full_len are updated. Unbreak the logic a bit more by mapping both O_NONBLOCK and SPLICE_F_NONBLOCK to MSG_DONTWAIT. This way we align with man splice(2) in regard to errno EAGAIN: SPLICE_F_NONBLOCK was specified in flags or one of the file descriptors had been marked as nonblocking (O_NONBLOCK), and the operation would block. Fixes: 5121197 ("kcm: close race conditions on sk_receive_queue") Fixes: 9168735 ("kcm: Splice support") Signed-off-by: Michal Luczaj <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Commit ff3fbcd ("selftests: tc: Add generic erspan_opts matching support for tc-flower") started triggering the following kmemleak warning: unreferenced object 0xffff888015fb0e00 (size 512): comm "softirq", pid 0, jiffies 4294679065 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff ........@....... 41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00 AiY............. backtrace (crc 30b71e8b): __kmalloc_noprof+0x359/0x460 metadata_dst_alloc+0x28/0x490 erspan_rcv+0x4f1/0x1160 [ip_gre] gre_rcv+0x217/0x240 [ip_gre] gre_rcv+0x1b8/0x400 [gre] ip_protocol_deliver_rcu+0x31d/0x3a0 ip_local_deliver_finish+0x37d/0x620 ip_local_deliver+0x174/0x460 ip_rcv+0x52b/0x6b0 __netif_receive_skb_one_core+0x149/0x1a0 process_backlog+0x3c8/0x1390 __napi_poll.constprop.0+0xa1/0x390 net_rx_action+0x59b/0xe00 handle_softirqs+0x22b/0x630 do_softirq+0xb1/0xf0 __local_bh_enable_ip+0x115/0x150 vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to skb_dst_drop to drop any existing entry. Cc: David Ahern <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Fixes: 9ff7438 ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: Stanislav Fomichev <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Make sure to drop the reference to the ptp device taken by of_find_device_by_node() when querying the time stamping capabilities. Note that holding a reference to the ptp device does not prevent its driver data from going away. Fixes: 17ae0b0 ("dpaa_eth: add the get_ts_info interface for ethtool") Cc: [email protected] # 4.19 Cc: Yangbo Lu <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Make sure to drop the references to the IERB OF node and platform device taken by of_parse_phandle() and of_find_device_by_node() during probe. Fixes: e7d48e5 ("net: enetc: add a mini driver for the Integrated Endpoint Register Block") Cc: [email protected] # 5.13 Cc: Vladimir Oltean <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Make sure to drop the reference to the ptp device taken by of_find_device_by_node() when querying the time stamping capabilities. Note that holding a reference to the ptp device does not prevent its driver data from going away. Fixes: 7349a74 ("net: ethernet: gianfar_ethtool: get phc index through drvdata") Cc: [email protected] # 4.18 Cc: Yangbo Lu <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The reference count to the WED devices has already been incremented when looking them up using of_find_device_by_node() so drop the bogus additional reference taken during probe. Fixes: 804775d ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)") Cc: [email protected] # 5.19 Cc: Felix Fietkau <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Make sure to drop the references to the IEP OF node and device taken by of_parse_phandle() and of_find_device_by_node() when looking up IEP devices during probe. Drop the bogus additional reference taken on successful lookup so that the device is released correctly by icss_iep_put(). Fixes: c1e0230 ("net: ti: icss-iep: Add IEP driver") Cc: [email protected] # 6.6 Cc: Roger Quadros <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Paolo spotted hangs in NIPA running driver tests against virtio.
The tests hang in virtnet_close() -> virtnet_napi_tx_disable().
The problem is only reproducible if running multiple of our tests
in sequence (I used TEST_PROGS="xdp.py ping.py netcons_basic.sh \
netpoll_basic.py stats.py"). Initial suspicion was that this is
a simple case of double-disable of NAPI, but instrumenting the
code reveals:
Deadlocked on NAPI ffff888007cd82c0 (virtnet_poll_tx):
state: 0x37, disabled: false, owner: 0, listed: false, weight: 64
The NAPI was not in fact disabled, owner is 0 (rather than -1),
so the NAPI "thinks" it's scheduled for CPU 0 but it's not listed
(!list_empty(&n->poll_list) => false). It seems odd that normal NAPI
processing would wedge itself like this.
Better suspicion is that netpoll gets enabled while NAPI is polling,
and also grabs the NAPI instance. This confuses napi_complete_done():
[netpoll] [normal NAPI]
napi_poll()
have = netpoll_poll_lock()
rcu_access_pointer(dev->npinfo)
return NULL # no netpoll
__napi_poll()
->poll(->weight)
poll_napi()
cmpxchg(->poll_owner, -1, cpu)
poll_one_napi()
set_bit(NAPI_STATE_NPSVC, ->state)
napi_complete_done()
if (NAPIF_STATE_NPSVC)
return false
# exit without clearing SCHED
This feels very unlikely, but perhaps virtio has some interactions
with the hypervisor in the NAPI ->poll that makes the race window
larger?
Best I could to to prove the theory was to add and trigger this
warning in napi_poll (just before netpoll_poll_unlock()):
WARN_ONCE(!have && rcu_access_pointer(n->dev->npinfo) &&
napi_is_scheduled(n) && list_empty(&n->poll_list),
"NAPI race with netpoll %px", n);
If this warning hits the next virtio_close() will hang.
This patch survived 30 test iterations without a hang (without it
the longest clean run was around 10). Credit for triggering this
goes to Breno's recent netconsole tests.
Fixes: 1da177e ("Linux-2.6.12-rc2")
Reported-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Syzbot reported a WARNING in taprio_get_start_time(). When link speed is 470,589 or greater, q->picos_per_byte becomes too small, causing length_to_duration(q, ETH_ZLEN) to return zero. This zero value leads to validation failures in fill_sched_entry() and parse_taprio_schedule(), allowing arbitrary values to be assigned to entry->interval and cycle_time. As a result, sched->cycle can become zero. Since SPEED_800000 is the largest defined speed in include/uapi/linux/ethtool.h, this issue can occur in realistic scenarios. To ensure length_to_duration() returns a non-zero value for minimum-sized Ethernet frames (ETH_ZLEN = 60), picos_per_byte must be at least 17 (60 * 17 > PSEC_PER_NSEC which is 1000). This patch enforces a minimum value of 17 for picos_per_byte when the calculated value would be lower, and adds a warning message to inform users that scheduling accuracy may be affected at very high link speeds. Fixes: fb66df2 ("net/sched: taprio: extend minimum interval restriction to entire cycle too") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=398e1ee4ca2cac05fddb Signed-off-by: Takamitsu Iwai <[email protected]> Signed-off-by: NipaLocal <nipa@local>
According to the 1588 standard, it is possible to use both unicast and multicast frames to send the PTP information. It was noticed that if the frames were unicast they were not processed by the analyzer meaning that they were not timestamped. Therefore fix this to match also these unicast frames. Fixes: ab2bf93 ("net: phy: mscc: 1588 block initialization") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
tc_actions.sh keeps hanging the forwarding tests. sdf@: tdc & tdc-dbg started intermittenly failing around Sep 25th Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
kmemleak auto scan could be a source of latency for the tests. We run a full scan after the tests manually, we don't need the autoscan thread to be enabled. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
7 times, most recently
from
c82c120 to
d97a5de
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Test kernel config fix