aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-17audit,io_uring,io-wq: call __audit_uring_exit for dummy contextsJulian Orth2-1/+7
Not calling the function for dummy contexts will cause the context to not be reset. During the next syscall, this will cause an error in __audit_syscall_entry: WARN_ON(context->context != AUDIT_CTX_UNUSED); WARN_ON(context->name_count); if (context->context != AUDIT_CTX_UNUSED || context->name_count) { audit_panic("unrecoverable error in audit_syscall_entry()"); return; } These problematic dummy contexts are created via the following call chain: exit_to_user_mode_prepare -> arch_do_signal_or_restart -> get_signal -> task_work_run -> tctx_task_work -> io_req_task_submit -> io_issue_sqe -> audit_uring_entry Cc: [email protected] Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to io_uring") Signed-off-by: Julian Orth <[email protected]> [PM: subject line tweaks] Signed-off-by: Paul Moore <[email protected]>
2022-05-17io_uring: don't attempt to IOPOLL for MSG_RING requestsJens Axboe1-0/+3
We gate whether to IOPOLL for a request on whether the opcode is allowed on a ring setup for IOPOLL and if it's got a file assigned. MSG_RING is the only one that allows a file yet isn't pollable, it's merely supported to allow communication on an IOPOLL ring, not because we can poll for completion of it. Put the assigned file early and clear it, so we don't attempt to poll for it. Reported-by: [email protected] Fixes: 3f1d52abf098 ("io_uring: defer msg-ring file validity check until command issue") Signed-off-by: Jens Axboe <[email protected]>
2022-05-17ice: Fix interrupt moderation settings getting clearedMichal Wilczynski2-11/+16
Adaptive-rx and Adaptive-tx are interrupt moderation settings that can be enabled/disabled using ethtool: ethtool -C ethX adaptive-rx on/off adaptive-tx on/off Unfortunately those settings are getting cleared after changing number of queues, or in ethtool world 'channels': ethtool -L ethX rx 1 tx 1 Clearing was happening due to introduction of bit fields in ice_ring_container struct. This way only itr_setting bits were rebuilt during ice_vsi_rebuild_set_coalesce(). Introduce an anonymous struct of bitfields and create a union to refer to them as a single variable. This way variable can be easily saved and restored. Fixes: 61dc79ced7aa ("ice: Restore interrupt throttle settings after VSI rebuild") Signed-off-by: Michal Wilczynski <[email protected]> Tested-by: Gurucharan <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2022-05-17ice: fix possible under reporting of ethtool Tx and Rx statisticsPaul Greenwalt1-3/+4
The hardware statistics counters are not cleared during resets so the drivers first access is to initialize the baseline and then subsequent reads are for reporting the counters. The statistics counters are read during the watchdog subtask when the interface is up. If the baseline is not initialized before the interface is up, then there can be a brief window in which some traffic can be transmitted/received before the initial baseline reading takes place. Directly initialize ethtool statistics in driver open so the baseline will be initialized when the interface is up, and any dropped packets incremented before the interface is up won't be reported. Fixes: 28dc1b86f8ea9 ("ice: ignore dropped packets during init") Signed-off-by: Paul Greenwalt <[email protected]> Tested-by: Gurucharan <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2022-05-17ice: fix crash when writing timestamp on RX ringsArkadiusz Kubalewski1-4/+15
Do not allow to write timestamps on RX rings if PF is being configured. When PF is being configured RX rings can be freed or rebuilt. If at the same time timestamps are updated, the kernel will crash by dereferencing null RX ring pointer. PID: 1449 TASK: ff187d28ed658040 CPU: 34 COMMAND: "ice-ptp-0000:51" #0 [ff1966a94a713bb0] machine_kexec at ffffffff9d05a0be #1 [ff1966a94a713c08] __crash_kexec at ffffffff9d192e9d #2 [ff1966a94a713cd0] crash_kexec at ffffffff9d1941bd #3 [ff1966a94a713ce8] oops_end at ffffffff9d01bd54 #4 [ff1966a94a713d08] no_context at ffffffff9d06bda4 #5 [ff1966a94a713d60] __bad_area_nosemaphore at ffffffff9d06c10c #6 [ff1966a94a713da8] do_page_fault at ffffffff9d06cae4 #7 [ff1966a94a713de0] page_fault at ffffffff9da0107e [exception RIP: ice_ptp_update_cached_phctime+91] RIP: ffffffffc076db8b RSP: ff1966a94a713e98 RFLAGS: 00010246 RAX: 16e3db9c6b7ccae4 RBX: ff187d269dd3c180 RCX: ff187d269cd4d018 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff187d269cfcc644 R8: ff187d339b9641b0 R9: 0000000000000000 R10: 0000000000000002 R11: 0000000000000000 R12: ff187d269cfcc648 R13: ffffffff9f128784 R14: ffffffff9d101b70 R15: ff187d269cfcc640 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ff1966a94a713ea0] ice_ptp_periodic_work at ffffffffc076dbef [ice] #9 [ff1966a94a713ee0] kthread_worker_fn at ffffffff9d101c1b #10 [ff1966a94a713f10] kthread at ffffffff9d101b4d #11 [ff1966a94a713f50] ret_from_fork at ffffffff9da0023f Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Signed-off-by: Arkadiusz Kubalewski <[email protected]> Reviewed-by: Michal Schmidt <[email protected]> Tested-by: Dave Cain <[email protected]> Tested-by: Gurucharan <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2022-05-17rtw89: pci: only mask out INT indicator register for disable interrupt v1Ping-Ke Shih1-3/+0
The design of INT indicator register (R_AX_PCIE_HIMR00_V1) is to reduce IO during frequent interrupts, because it can stop chip sending interrupt to host if we just set this indicator to 0, not all IMR(s). This indicator register looks like a root interrupt controller of wifi chip. However, we can't set all other IMR(s) to 0 during we are running on interrupt service routine, or the indicator register can't reflect the status of certain interrupt happened during this period, and then miss some interrupts especially SER interrupt events. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17rtw89: convert rtw89_band to nl80211_band preciselyZong-Zhe Yang4-11/+29
Before 6 GHz band was supported, i.e. only 2 GHz and 5 GHz, they were the same from the numerical point of view. However, after 6 GHz band support, we need to do this conversion logically. Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17rtw89: 8852c: update txpwr tables to HALRF_027_00_052Zong-Zhe Yang1-1857/+1857
Update notes: update the following to HALRF_027_00_052 TX power by rate table TX power limit table TX power limit RU table TX shape table doesn't seem to be changed on HALRF_027_00_052 Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17rtw89: cfo: check mac_id to avoid out-of-boundsPing-Ke Shih1-0/+5
Somehow, hardware reports incorrect mac_id and pollute memory. Check index before we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: <IRQ> show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 </IRQ> <TASK> __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17rtw89: 8852c: set TX antenna pathPing-Ke Shih1-4/+5
To make user space can set TX antenna via iw command. Then, we can diagnose antenna is connected properly or not, and measure TX power in single path. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17rtw89: add ieee80211::sta_rc_update opsPing-Ke Shih3-5/+22
When peer's NSS, rate or bandwidth is changed, we update RA(rate adaptive) mask to ensure transmitting packets properly. Signed-off-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-17wireless: Fix Makefile to be in alphabetical orderSrinivasan R1-1/+1
Fix quantenna to be in the right order Signed-off-by: Srinivasan R <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/MA1PR01MB26992E104B006B340C3C3A84C1CA9@MA1PR01MB2699.INDPRD01.PROD.OUTLOOK.COM
2022-05-17net: phy: marvell: Add errata section 5.1 for Alaska PHYLeszek Polak1-0/+37
As per Errata Section 5.1, if EEE is intended to be used, some register writes must be done once after every hardware reset. This patch now adds the necessary register writes as listed in the Marvell errata. Without this fix we experience ethernet problems on some of our boards equipped with a new version of this ethernet PHY (different supplier). The fix applies to Marvell Alaska 88E1510/88E1518/88E1512/88E1514 Rev. A0. Signed-off-by: Leszek Polak <[email protected]> Signed-off-by: Stefan Roese <[email protected]> Cc: Marek Behún <[email protected]> Cc: Andrew Lunn <[email protected]> Cc: Heiner Kallweit <[email protected]> Cc: Russell King <[email protected]> Cc: David S. Miller <[email protected]> Reviewed-by: Marek Behún <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net: qede: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi1-1/+0
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Minghao Chi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17mac80211: refactor freeing the next_beaconJohannes Berg1-27/+18
We have this code seven times, refactor it into a separate function. Signed-off-by: Johannes Berg <[email protected]>
2022-05-17net: vxge: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi1-2/+0
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Minghao Chi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17qed: Remove unnecessary synchronize_irq() before free_irq()Minghao Chi1-1/+0
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Minghao Chi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17cfg80211: fix kernel-doc for cfg80211_beacon_dataJohannes Berg1-1/+1
The kernel-doc comment is formatted badly, resulting in a warning: include/net/cfg80211.h:1188: warning: bad line: [...] Fix that. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2022-05-17ax25: merge repeat codes in ax25_dev_device_down()Lu Wei1-12/+10
Merge repeat codes to reduce the duplication. Signed-off-by: Lu Wei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()Zixuan Fu1-0/+4
In vmxnet3_rq_create(), when dma_alloc_coherent() fails, vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all() -> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls vmxnet3_force_close() -> dev_close() in error handling code. And the driver calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all() -> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(), rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing a NULL pointer dereference. To fix this possible bug, an if statement is added to check whether rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so. The error log in our fault-injection testing is shown as follows: [ 65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008 ... [ 65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3] ... [ 65.227977] Call Trace: ... [ 65.228262] vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3] [ 65.228580] vmxnet3_close+0x2c4/0x3f0 [vmxnet3] [ 65.228866] __dev_close_many+0x288/0x350 [ 65.229607] dev_close_many+0xa4/0x480 [ 65.231124] dev_close+0x138/0x230 [ 65.231933] vmxnet3_force_close+0x1f0/0x240 [vmxnet3] [ 65.232248] vmxnet3_change_mtu+0x75d/0x920 [vmxnet3] ... Fixes: d1a890fa37f27 ("net: VMware virtual Ethernet NIC driver: vmxnet3") Reported-by: TOTE Robot <[email protected]> Signed-off-by: Zixuan Fu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf()Zixuan Fu1-0/+2
In vmxnet3_rq_alloc_rx_buf(), when dma_map_single() fails, rbi->skb is freed immediately. Similarly, in another branch, when dma_map_page() fails, rbi->page is also freed. In the two cases, vmxnet3_rq_alloc_rx_buf() returns an error to its callers vmxnet3_rq_init() -> vmxnet3_rq_init_all() -> vmxnet3_activate_dev(). Then vmxnet3_activate_dev() calls vmxnet3_rq_cleanup_all() in error handling code, and rbi->skb or rbi->page are freed again in vmxnet3_rq_cleanup_all(), causing use-after-free bugs. To fix these possible bugs, rbi->skb and rbi->page should be cleared after they are freed. The error log in our fault-injection testing is shown as follows: [ 14.319016] BUG: KASAN: use-after-free in consume_skb+0x2f/0x150 ... [ 14.321586] Call Trace: ... [ 14.325357] consume_skb+0x2f/0x150 [ 14.325671] vmxnet3_rq_cleanup_all+0x33a/0x4e0 [vmxnet3] [ 14.326150] vmxnet3_activate_dev+0xb9d/0x2ca0 [vmxnet3] [ 14.326616] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.361675] Allocated by task 351: ... [ 14.362688] __netdev_alloc_skb+0x1b3/0x6f0 [ 14.362960] vmxnet3_rq_alloc_rx_buf+0x1b0/0x8d0 [vmxnet3] [ 14.363317] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.363661] vmxnet3_open+0x387/0x470 [vmxnet3] ... [ 14.367309] [ 14.367412] Freed by task 351: ... [ 14.368932] __dev_kfree_skb_any+0xd2/0xe0 [ 14.369193] vmxnet3_rq_alloc_rx_buf+0x71e/0x8d0 [vmxnet3] [ 14.369544] vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3] [ 14.369883] vmxnet3_open+0x387/0x470 [vmxnet3] [ 14.370174] __dev_open+0x28a/0x420 [ 14.370399] __dev_change_flags+0x192/0x590 [ 14.370667] dev_change_flags+0x7a/0x180 [ 14.370919] do_setlink+0xb28/0x3570 [ 14.371150] rtnl_newlink+0x1160/0x1740 [ 14.371399] rtnetlink_rcv_msg+0x5bf/0xa50 [ 14.371661] netlink_rcv_skb+0x1cd/0x3e0 [ 14.371913] netlink_unicast+0x5dc/0x840 [ 14.372169] netlink_sendmsg+0x856/0xc40 [ 14.372420] ____sys_sendmsg+0x8a7/0x8d0 [ 14.372673] __sys_sendmsg+0x1c2/0x270 [ 14.372914] do_syscall_64+0x41/0x90 [ 14.373145] entry_SYSCALL_64_after_hwframe+0x44/0xae ... Fixes: 5738a09d58d5a ("vmxnet3: fix checks for dma mapping errors") Reported-by: TOTE Robot <[email protected]> Signed-off-by: Zixuan Fu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net/mlxbf_gige: use eth_zero_addr() to clear mac addressLu Wei1-1/+1
Use eth_zero_addr() to clear mac address instead of memset(). Signed-off-by: Lu Wei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17ethernet/ti: delete if NULL check befort devm_kfreeBernard Zhao1-9/+4
devm_kfree check the pointer, there is no need to check before devm_kfree call. This change is to cleanup the code a bit. Signed-off-by: Bernard Zhao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17xfrm: set dst dev to blackhole_netdev instead of loopback_dev in ifdownXin Long1-1/+1
The global blackhole_netdev has replaced pernet loopback_dev to become the one given to the object that holds an netdev when ifdown in many places of ipv4 and ipv6 since commit 8d7017fd621d ("blackhole_netdev: use blackhole_netdev to invalidate dst entries"). Especially after commit faab39f63c1f ("net: allow out-of-order netdev unregistration"), it's no longer safe to use loopback_dev that may be freed before other netdev. This patch is to set dst dev to blackhole_netdev instead of loopback_dev in ifdown. v1->v2: - add Fixes tag as Eric suggested. Fixes: faab39f63c1f ("net: allow out-of-order netdev unregistration") Signed-off-by: Xin Long <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/e8c87482998ca6fcdab214f5a9d582899ec0c648.1652665047.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net: systemport: Fix an error handling path in bcm_sysport_probe()Christophe JAILLET1-2/+4
if devm_clk_get_optional() fails, we still need to go through the error handling path. Add the missing goto. Fixes: 6328a126896ea ("net: systemport: Manage Wake-on-LAN clock") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/99d70634a81c229885ae9e4ee69b2035749f7edc.1652634040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Paolo Abeni <[email protected]>
2022-05-17net: lan966x: Fix assignment of the MAC addressHoratiu Vultur1-0/+28
The following two scenarios were failing for lan966x. 1. If the port had the address X and then trying to assign the same address, then the HW was just removing this address because first it tries to learn new address and then delete the old one. As they are the same the HW remove it. 2. If the port eth0 was assigned the same address as one of the other ports eth1 then when assigning back the address to eth0 then the HW was deleting the address of eth1. The case 1. is fixed by checking if the port has already the same address while case 2. is fixed by checking if the address is used by any other port. Fixes: e18aba8941b40b ("net: lan966x: add mactable support") Signed-off-by: Horatiu Vultur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-05-16net: ethernet: Fix unmet direct dependencies detected for NVMEM_SUNPLUS_OCOTPWells Lu1-3/+0
Removed unnecessary: select COMMON_CLK_SP7021 select RESET_SUNPLUS select NVMEM_SUNPLUS_OCOTP from Kconfig. Reported-by: kernel test robot <[email protected]> Signed-off-by: Wells Lu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16Merge tag 'linux-can-next-for-5.19-20220516' of ↵Jakub Kicinski8-43/+119
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2022-05-16 the first 2 patches are by me and target the CAN raw protocol. The 1st removes an unneeded assignment, the other one adds support for SO_TXTIME/SCM_TXTIME. Oliver Hartkopp contributes 2 patches for the ISOTP protocol. The 1st adds support for transmission without flow control, the other let's bind() return an error on incorrect CAN ID formatting. Geert Uytterhoeven contributes a patch to clean up ctucanfd's Kconfig file. Vincent Mailhol's patch for the slcan driver uses the proper function to check for invalid CAN frames in the xmit callback. The next patch is by Geert Uytterhoeven and makes the interrupt-names of the renesas,rcar-canfd dt bindings mandatory. A patch by my update the ctucanfd dt bindings to include the common CAN controller bindings. The last patch is by Akira Yokosawa and fixes a breakage the ctucanfd's documentation. * tag 'linux-can-next-for-5.19-20220516' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: docs: ctucanfd: Use 'kernel-figure' directive instead of 'figure' dt-bindings: can: ctucanfd: include common CAN controller bindings dt-bindings: can: renesas,rcar-canfd: Make interrupt-names required can: slcan: slc_xmit(): use can_dropped_invalid_skb() instead of manual check can: ctucanfd: Let users select instead of depend on CAN_CTUCANFD can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting can: isotp: add support for transmission without flow control can: raw: add support for SO_TXTIME/SCM_TXTIME can: raw: raw_sendmsg(): remove not needed setting of skb->sk ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16Revert "PCI: aardvark: Rewrite IRQ code to chained IRQ handler"Pali Rohár1-26/+22
This reverts commit 1571d67dc190e50c6c56e8f88cdc39f7cc53166e. This commit broke support for setting interrupt affinity. It looks like that it is related to the chained IRQ handler. Revert this commit until issue with setting interrupt affinity is fixed. Fixes: 1571d67dc190 ("PCI: aardvark: Rewrite IRQ code to chained IRQ handler") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2022-05-16Merge branch 'net-skb-remove-skb_data_area_size'Jakub Kicinski3-13/+5
Ricardo Martinez says: ==================== net: skb: Remove skb_data_area_size() This patch series removes the skb_data_area_size() helper, replacing it in t7xx driver with the size used during skb allocation. https://lore.kernel.org/netdev/CAHNKnsTmH-rGgWi3jtyC=ktM1DW2W1VJkYoTMJV2Z_Bt498bsg@mail.gmail.com/ ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16net: skb: Remove skb_data_area_size()Ricardo Martinez1-5/+0
skb_data_area_size() is not needed. As Jakub pointed out [1]: For Rx, drivers can use the size passed during skb allocation or use skb_tailroom(). For Tx, drivers should use skb_headlen(). [1] https://lore.kernel.org/netdev/CAHNKnsTmH-rGgWi3jtyC=ktM1DW2W1VJkYoTMJV2Z_Bt498bsg@mail.gmail.com/ Signed-off-by: Ricardo Martinez <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Sergey Ryazanov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16net: wwan: t7xx: Avoid calls to skb_data_area_size()Ricardo Martinez2-8/+5
skb_data_area_size() helper was used to calculate the size of the DMA mapped buffer passed to the HW. Instead of doing this, use the size passed to allocate the skbs. Signed-off-by: Ricardo Martinez <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Sergey Ryazanov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16Merge branch 'mptcp-updates-for-net-next'Jakub Kicinski3-12/+16
Mat Martineau says: ==================== mptcp: Updates for net-next Three independent fixes/features from the MPTCP tree: Patch 1 is a selftest workaround for older iproute2 packages. Patch 2 removes superfluous locks that were added with recent MP_FAIL patches. Patch 3 adds support for the TCP_DEFER_ACCEPT sockopt. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16mptcp: sockopt: add TCP_DEFER_ACCEPT supportFlorian Westphal1-0/+15
Support this via passthrough to the underlying tcp listener socket. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/271 Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16Revert "mptcp: add data lock for sk timers"Paolo Abeni1-12/+0
This reverts commit 4293248c6704b854bf816aa1967e433402bee11c. Additional locks are not needed, all the touched sections are already under mptcp socket lock protection. Fixes: 4293248c6704 ("mptcp: add data lock for sk timers") Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16selftests: mptcp: fix a mp_fail test warningGeliang Tang1-0/+1
Old tc versions (iproute2 5.3) show actions in multiple lines, not a single line. Then the following unexpected MP_FAIL selftest output occurs: file received by server has inverted byte at 169 ./mptcp_join.sh: line 1277: [: [{"total acts":1},{"actions":[{"order":0 pedit ,"control_action":{"type":"pipe"}keys 1 index 1 ref 1 bind 1,"installed":0,"last_used":0 key #0 at 148: val ff000000 mask ffffffff 5: integer expression expected 001 Infinite map syn[ ok ] - synack[ ok ] - ack[ ok ] sum[ ok ] - csum [ ok ] ftx[ ok ] - failrx[ ok ] rtx[ ok ] - rstrx [ ok ] itx[ ok ] - infirx[ ok ] ftx[ ok ] - failrx[ ok ] invert This patch adds a 'grep' before 'sed' to fix this. Fixes: b6e074e171bc ("selftests: mptcp: add infinite map testcase") Reviewed-by: Matthieu Baerts <[email protected]> Signed-off-by: Geliang Tang <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16docs: ctucanfd: Use 'kernel-figure' directive instead of 'figure'Akira Yokosawa1-2/+2
Two issues were observed in the ReST doc added by commit c3a0addefbde ("docs: ctucanfd: CTU CAN FD open-source IP core documentation.") with Sphinx versions 2.4.4 and 4.5.0. The plain "figure" directive broke "make pdfdocs" due to a missing PDF figure. For conversion of SVG -> PDF to work, the "kernel-figure" directive, which is an extension for kernel documentation, should be used instead. The directive of "code:: raw" causes a warning from both "make htmldocs" and "make pdfdocs", which reads: [...]/can/ctu/ctucanfd-driver.rst:75: WARNING: Pygments lexer name 'raw' is not known A plain literal-block marker should suffice where no syntax highlighting is intended. Fix the issues by using suitable directive and marker. Fixes: c3a0addefbde ("docs: ctucanfd: CTU CAN FD open-source IP core documentation.") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Akira Yokosawa <[email protected]> Acked-by: Pavel Pisa <[email protected]> Cc: Martin Jerabek <[email protected]> Cc: Ondrej Ille <[email protected]> Cc: Marc Kleine-Budde <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16dt-bindings: can: ctucanfd: include common CAN controller bindingsMarc Kleine-Budde1-0/+3
Since commit | 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml") there is a common CAN controller binding. Add this to the ctucanfd binding. Cc: Ondrej Ille <[email protected]> Acked-by: Pavel Pisa <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16net: dsa: realtek: rtl8366rb: Serialize indirect PHY register accessAlvin Šipraga1-12/+25
Lock the regmap during the whole PHY register access routines in rtl8366rb. Signed-off-by: Alvin Šipraga <[email protected]> Tested-by: Linus Walleij <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16ptp: ocp: have adjtime handle negative delta_ns correctlyJonathan Lemon1-2/+3
delta_ns is a s64, but it was being passed ptp_ocp_adjtime_coarse as an u64. Also, it turns out that timespec64_add_ns() only handles positive values, so perform the math with set_normalized_timespec(). Fixes: 90f8f4c0e3ce ("ptp: ocp: Add ptp_ocp_adjtime_coarse for large adjustments") Suggested-by: Vadim Fedorenko <[email protected]> Signed-off-by: Jonathan Lemon <[email protected]> Acked-by: Vadim Fedorenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16dt-bindings: can: renesas,rcar-canfd: Make interrupt-names requiredGeert Uytterhoeven1-1/+2
The Renesas R-Car CAN FD Controller always uses two or more interrupts. Make the interrupt-names properties a required property, to make it easier to identify the individual interrupts. Update the example accordingly. Link: https://lore.kernel.org/all/a68e65955e0df4db60233d468f348203c2e7b940.1651512451.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: slcan: slc_xmit(): use can_dropped_invalid_skb() instead of manual checkVincent Mailhol1-2/+2
slcan does a manual check in slc_xmit() to verify if the skb is valid. This check is incomplete, use instead can_dropped_invalid_skb(). Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: ctucanfd: Let users select instead of depend on CAN_CTUCANFDGeert Uytterhoeven1-3/+3
The CTU CAN-FD IP core is only useful when used with one of the corresponding PCI/PCIe or platform (FPGA, SoC) drivers, which depend on PCI resp. OF. Hence make the users select the core driver code, instead of letting then depend on it. Keep the core code config option visible when compile-testing, to maintain compile-coverage. Link: https://lore.kernel.org/all/887b7440446b6244a20a503cc6e8dc9258846706.1652104941.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Pavel Pisa <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formattingOliver Hartkopp1-0/+5
Commit 3ea566422cbd ("can: isotp: sanitize CAN ID checks in isotp_bind()") checks the given CAN ID address information by sanitizing the input values. This check (silently) removes obsolete bits by masking the given CAN IDs. Derek Will suggested to give a feedback to the application programmer when the 'sanitizing' was actually needed which means the programmer provided CAN ID content in a wrong format (e.g. SFF CAN IDs with a CAN ID > 0x7FF). Link: https://lore.kernel.org/all/[email protected] Suggested-by: Derek Will <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: isotp: add support for transmission without flow controlOliver Hartkopp2-33/+92
Usually the ISO 15765-2 protocol is a point-to-point protocol to transfer segmented PDUs to a dedicated receiver. This receiver sends a flow control message to specify protocol options and timings (e.g. block size / STmin). The so called functional addressing communication allows a 1:N communication but is limited to a single frame length. This new CAN_ISOTP_CF_BROADCAST allows an unconfirmed 1:N communication with PDU length that would not fit into a single frame. This feature is not covered by the ISO 15765-2 standard. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: raw: add support for SO_TXTIME/SCM_TXTIMEMarc Kleine-Budde1-1/+10
This patch calls into sock_cmsg_send() to parse the user supplied control information into a struct sockcm_cookie. Then assign the requested transmit time to the skb. This makes it possible to use the Earliest TXTIME First (ETF) packet scheduler with the CAN_RAW protocol. The user can send a CAN_RAW frame with a TXTIME and the kernel (with the ETF scheduler) will take care of sending it to the network interface. Link: https://lore.kernel.org/all/[email protected] Acked-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16can: raw: raw_sendmsg(): remove not needed setting of skb->skMarc Kleine-Budde1-1/+0
The skb in raw_sendmsg() is allocated with sock_alloc_send_skb(), which subsequently calls sock_alloc_send_pskb() -> skb_set_owner_w(), which assigns "skb->sk = sk". This patch removes the not needed setting of skb->sk. Link: https://lore.kernel.org/all/[email protected] Acked-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-16net: phy: micrel: Use the kszphy probe/suspend/resumeFabio Estevam1-2/+3
Now that it is possible to use .probe without having .driver_data, let KSZ8061 use the kszphy specific hooks for probe,suspend and resume, which is preferred. Switch to using the dedicated kszphy probe/suspend/resume functions. Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16net: phy: micrel: Allow probing without .driver_dataFabio Estevam1-5/+6
Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-05-16netfilter: conntrack: remove pr_debug callsites from tcp trackerFlorian Westphal1-48/+4
They are either obsolete or useless. Those in the normal processing path cannot be enabled on a production system; they generate too much noise. One pr_debug call resides in an error path and does provide useful info, merge it with the existing nf_log_invalid(). Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.