- 27 Jan, 2022 13 commits
-
-
Eric Dumazet authored
For some reason, raw_bind() forgot to lock the socket. BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0: raw_bind+0x1b0/0x250 net/ipv4/raw.c:739 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443 __sys_bind+0x14b/0x1b0 net/socket.c:1697 __do_sys_bind net/socket.c:1708 [inline] __se_sys_bind net/socket.c:1706 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1706 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1: __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x0003007f Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Add missing headers to the IP entry. Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
include/linux/linkmode.h and include/linux/mii.h do not match anything in MAINTAINERS. Looks like they should be under Ethernet PHY. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Jisheng Zhang authored
When readl_poll_timeout() timeout, we'd better directly use its return value. Before this patch: [ 2.145528] dwmac-sun8i: probe of 4500000.ethernet failed with error -14 After this patch: [ 2.138520] dwmac-sun8i: probe of 4500000.ethernet failed with error -110 Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Nikolay Aleksandrov authored
When dumping vlan options for a single net device we send the same entries infinitely because user-space expects a 0 return at the end but we keep returning skb->len and restarting the dump on retry. Fix it by returning the value from br_vlan_dump_dev() if it completed or there was an error. The only case that must return skb->len is when the dump was incomplete and needs to continue (-EMSGSIZE). Reported-by:
Benjamin Poirier <bpoirier@nvidia.com> Fixes: 8dcea187 ("net: bridge: vlan: add rtm definitions and dump support") Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
David S. Miller authored
Mohammad Athari Bin Ismail says: ==================== Fix PTP issue in stmmac This patch series to fix PTP issue in stmmac related to: 1/ PTP clock source configuration during initialization. 2/ PTP initialization during resume from suspend. ==================== Signed-off-by: -
Mohammad Athari Bin Ismail authored
When resume from suspend, besides skipping PTP registration, it also skipping PTP HW initialization. This could cause PTP clock not able to operate properly when resume from suspend. To fix this, only stmmac_ptp_register() is skipped when resume from suspend. Fixes: fe131929 ("stmmac: Don't init ptp again when resume from suspend/hibernation") Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.com> Signed-off-by:
-
Mohammad Athari Bin Ismail authored
For Intel platform, it is required to configure PTP clock source prior PTP initialization in MAC. So, need to move ptp_clk_freq_config execution from stmmac_ptp_register() to stmmac_init_ptp(). Fixes: 76da35dc ("stmmac: intel: Add PSE and PCH PTP clock source selection") Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
-
Guillaume Nault authored
This reverts commit b75326c2. This commit breaks Linux compatibility with USGv6 tests. The RFC this commit was based on is actually an expired draft: no published RFC currently allows the new behaviour it introduced. Without full IETF endorsement, the flash renumbering scenario this patch was supposed to enable is never going to work, as other IPv6 equipements on the same LAN will keep the 2 hours limit. Fixes: b75326c2 ("ipv6: Honor all IPv6 PIO Valid Lifetime values") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Jakub Kicinski authored
Leo Yan says: ==================== pid: Introduce helper task_is_in_root_ns() This patch series introduces a helper function task_is_in_init_pid_ns() to replace open code. The two patches are extracted from the original series [1] for network subsystem. As a plan, we can firstly land this patch set into kernel 5.18; there have 5 patches are left out from original series [1], as a next step, I will resend them for appropriate linux-next merging. [1] https://lore.kernel.org/lkml/20211208083320.472503-1-leo.yan@linaro.org/ ==================== Link: https://lore.kernel.org/r/20220126050427.605628-1-leo.yan@linaro.orgSigned-off-by:
-
Leo Yan authored
This patch replaces open code with task_is_in_init_pid_ns() to check if a task is in root PID namespace. Signed-off-by:
Leo Yan <leo.yan@linaro.org> Acked-by:
Balbir Singh <bsingharora@gmail.com> Signed-off-by:
-
Leo Yan authored
Currently the kernel uses open code in multiple places to check if a task is in the root PID namespace with the kind of format: if (task_active_pid_ns(current) == &init_pid_ns) do_something(); This patch creates a new helper function, task_is_in_init_pid_ns(), it returns true if a passed task is in the root PID namespace, otherwise returns false. So it will be used to replace open codes. Suggested-by:Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Acked-by:
-
Catherine Sullivan authored
Use GFP_ATOMIC when allocating pages out of the hotpath, continue to use GFP_KERNEL when allocating pages during setup. GFP_KERNEL will allow blocking which allows it to succeed more often in a low memory enviornment but in the hotpath we do not want to allow the allocation to block. Fixes: f5cedc84 ("gve: Add transmit and receive support") Signed-off-by:
Catherine Sullivan <csully@google.com> Signed-off-by:
David Awogbemila <awogbemila@google.com> Link: https://lore.kernel.org/r/20220126003843.3584521-1-awogbemila@google.comSigned-off-by:
-
- 26 Jan, 2022 11 commits
-
-
David S. Miller authored
Horatiu Vultur says: ==================== net: lan966x: Fixes for sleep in atomic context This patch series contains 2 fixes for lan966x that is sleeping in atomic context. The first patch fixes the injection of the frames while the second one fixes the updating of the MAC table. v1->v2: - correct the fix tag in the second patch, it was using the wrong sha. ==================== Signed-off-by: -
Horatiu Vultur authored
The function lan966x_mac_wait_for_completion is used to poll the status of the MAC table using the function readx_poll_timeout. The problem with this function is that is called also from atomic context. Therefore update the function to use readx_poll_timeout_atomic. Fixes: e18aba89 ("net: lan966x: add mactable support") Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
On lan966x, when injecting a frame it was polling the register QS_INJ_STATUS to see if it can continue with the injection of the frame. The problem was that it was using readx_poll_timeout which could sleep in atomic context. This patch fixes this issue by using readx_poll_timeout_atomic. Fixes: d28d6d2e ("net: lan966x: add port module support") Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== ethernet: fix some esoteric drivers after netdev->dev_addr constification Looking at recent fixes for drivers which don't get included with allmodconfig builds I thought it's worth grepping for more instances of: dev->dev_addr\[.*\] = This set contains the fixes. v2: add last 3 patches which fix drivers for the RiscPC ARM platform. Thanks to Arnd Bergmann for explaining how to build test that. ==================== Signed-off-by: -
Jakub Kicinski authored
netdev->dev_addr is const now. Compile tested rpc_defconfig w/ GCC 8.5. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Jakub Kicinski authored
netdev->dev_addr is const now. Compile tested rpc_defconfig w/ GCC 8.5. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Jakub Kicinski authored
netdev->dev_addr is const now. Compile tested rpc_defconfig w/ GCC 8.5. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Jakub Kicinski authored
netdev->dev_addr is const now. Compile tested bigsur_defconfig and sb1250_swarm_defconfig. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Jakub Kicinski authored
netdev->dev_addr is const now. Maintain the questionable offsetting in ndo_set_mac_address. Compile tested holly_defconfig and mpc7448_hpc2_defconfig. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Jakub Kicinski authored
This driver casts off the const and writes directly to netdev->dev_addr. This will result in a MAC address tree corruption and a warning. Compile tested ppc6xx_defconfig. Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Maxim Mikityanskiy authored
The current implementation of HTB offload doesn't support some parameters. Instead of ignoring them, actively return the EINVAL error when they are set to non-defaults. As this patch goes to stable, the driver API is not changed here. If future drivers support more offload parameters, the checks can be moved to the driver side. Note that the buffer and cbuffer parameters are also not supported, but the tc userspace tool assigns some default values derived from rate and ceil, and identifying these defaults in sch_htb would be unreliable, so they are still ignored. Fixes: d03b195b ("sch_htb: Hierarchical QoS hardware offload") Reported-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20220125100654.424570-1-maximmi@nvidia.comSigned-off-by:
-
- 25 Jan, 2022 6 commits
-
-
Thomas Bogendoerfer authored
Copy scattered mac address octets into an array then eth_hw_addr_set(). Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20220125144007.64407-1-tsbogend@alpha.franken.deSigned-off-by:
-
Yufeng Mo authored
Since some interrupt states may be cleared by hardware, the driver may receive an empty interrupt. Currently, the VF driver directly disables the vector0 interrupt in this case. As a result, the VF is unavailable. Therefore, the vector0 interrupt should be enabled in this case. Fixes: b90fcc5b ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset") Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Jakub Kicinski authored
Recent changes made netdev->dev_addr const, and it's passed directly to mpc52xx_fec_set_paddr(). Similar problem exists on the probe patch, the driver needs to call eth_hw_addr_set(). Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: adeef3e3 ("net: constify netdev->dev_addr") Signed-off-by:
-
Toke Høiland-Jørgensen authored
The cpsw driver didn't properly initialise the struct page_pool_params before calling page_pool_create(), which leads to crashes after the struct has been expanded with new parameters. The second Fixes tag below is where the buggy code was introduced, but because the code was moved around this patch will only apply on top of the commit in the first Fixes tag. Fixes: c5013ac1 ("net: ethernet: ti: cpsw: move set of common functions in cpsw_priv") Fixes: 9ed4050c ("net: ethernet: ti: cpsw: add XDP support") Reported-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Tested-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Hangyu Hua authored
ym needs to be free when ym->cmd != SIOCYAMSMCS. Fixes: 0781168e ("yam: fix a missing-check bug") Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Signed-off-by:
-
Jisheng Zhang authored
Currently, on EEE capable platforms, if EEE SW timer is used, the SW timer cause 1 wakeup/s even if the TX has successfully entered EEE. Remove this unnecessary wakeup by only calling mod_timer() if we haven't successfully entered EEE. Signed-off-by:
-
- 24 Jan, 2022 10 commits
-
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-5.17-20220124' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2022-01-24 The first patch updates the email address of Brian Silverman from his former employer to his private address. The next patch fixes DT bindings information for the tcan4x5x SPI CAN driver. The following patch targets the m_can driver and fixes the introduction of FIFO bulk read support. Another patch for the tcan4x5x driver, which fixes the max register value for the regmap config. The last patch for the flexcan driver marks the RX mailbox support for the MCF5441X as support. * tag 'linux-can-fixes-for-5.17-20220124' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: flexcan: mark RX via mailboxes as supported on MCF5441X can: tcan4x5x: regmap: fix max register value can: m_can: m_can_fifo_{read,write}: don't read or write from/to FIFO if length is 0 dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config mailmap: update email address of Brian Silverman ==================== Link: https://lore.kernel.org/r/20220124175955.3464134-1-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Most flexcan IP cores support 2 RX modes: - FIFO - mailbox The flexcan IP core on the MCF5441X cannot receive CAN RTR messages via mailboxes. However the mailbox mode is more performant. The commit | 1c45f577 ("can: flexcan: add ethtool support to change rx-rtr setting during runtime") added support to switch from FIFO to mailbox mode on these cores. After testing the mailbox mode on the MCF5441X by Angelo Dureghello, this patch marks it (without RTR capability) as supported. Further the IP core overview table is updated, that RTR reception via mailboxes is not supported. Link: https://lore.kernel.org/all/20220121084425.3141218-1-mkl@pengutronix.deTested-by:
Angelo Dureghello <angelo@kernel-space.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There are no further registers in the tcan4x5x making 0x87fc the biggest addressable register. This patch fixes the max register value of the regmap config from 0x8ffc to 0x87fc. Fixes: 6e1caaf8 ("can: tcan4x5x: fix max register value") Link: https://lore.kernel.org/all/20220119064011.2943292-1-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In order to optimize FIFO access, especially on m_can cores attached to slow busses like SPI, in patch | e3938177 ("can: m_can: Disable IRQs on FIFO bus errors") bulk read/write support has been added to the m_can_fifo_{read,write} functions. That change leads to the tcan driver to call regmap_bulk_{read,write}() with a length of 0 (for CAN frames with 0 data length). regmap treats this as an error: | tcan4x5x spi1.0 tcan4x5x0: FIFO write returned -22 This patch fixes the problem by not calling the cdev->ops->{read,write)_fifo() in case of a 0 length read/write. Fixes: e3938177 ("can: m_can: Disable IRQs on FIFO bus errors") Link: https://lore.kernel.org/all/20220114155751.2651888-1-mkl@pengutronix.de Cc: stable@vger.kernel.org Cc: Matt Kline <matt@bitbashing.io> Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Reported-by:
Michael Anochin <anochin@photo-meter.com> Signed-off-by:
-
Marc Kleine-Budde authored
This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32 doesn't fit into the MRAM. Use a depth of 16 instead. Fixes: 4edd396a ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver") Link: https://lore.kernel.org/all/20220119062951.2939851-1-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Brian Silverman's address at bluerivertech.com is not valid anymore, use Brian's private email address instead. Link: https://lore.kernel.org/all/20220110082359.2019735-1-mkl@pengutronix.de Cc: Brian Silverman <bsilver16384@gmail.com> Signed-off-by:
-
Jisheng Zhang authored
The tx_coalesce and mii_irq are not used at all now, so remove them. Signed-off-by:
-
Christophe JAILLET authored
Simplify code by using bitmap_weight() and bitmap_zero() instead of hand-writing these functions. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Igor Russkikh <irusskikh@marvell.com> Signed-off-by:
-
Xin Long authored
When 'ping' changes to use PING socket instead of RAW socket by: # sysctl -w net.ipv4.ping_group_range="0 100" the selftests 'router_broadcast.sh' will fail, as such command # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b can't receive the response skb by the PING socket. It's caused by mismatch of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket, as dif is vrf-h1 if dif's master was set to vrf-h1. This patch is to fix this regression by also checking the sk_bound_dev_if against sdif so that the packets can stil be received even if the socket is not bound to the vrf device but to the real iif. Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Wen Gu authored
We encountered a crash in smc_setsockopt() and it is caused by accessing smc->clcsock after clcsock was released. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53 RIP: 0010:smc_setsockopt+0x59/0x280 [smc] Call Trace: <TASK> __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f16ba83918e </TASK> This patch tries to fix it by holding clcsock_release_lock and checking whether clcsock has already been released before access. In case that a crash of the same reason happens in smc_getsockopt() or smc_switch_to_fallback(), this patch also checkes smc->clcsock in them too. And the caller of smc_switch_to_fallback() will identify whether fallback succeeds according to the return value. Fixes: fd57770d ("net/smc: wait for pending work before clcsock release_sock") Link: https://lore.kernel.org/lkml/5dd7ffd1-28e2-24cc-9442-1defec27375e@linux.ibm.com/T/Signed-off-by:
Wen Gu <guwen@linux.alibaba.com> Acked-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
