- Feb 11, 2021
-
-
Vignesh Raghavendra authored
AM642 SK board has 2 CPSW ports. Add DT entries for the same. Also add timesync_router DT node. Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Enable USB Super-Speed HOST port. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
WL1837 module is connected to SDHCI0 in AM642 SK. Enable it here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Cadence controller will not initiate autonomous speed change if strapped as Gen2. The Retrain Link bit is set as quirk to enable this speed change. Signed-off-by:
Nadeem Athani <nadeem@cadence.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210209144622.26683-3-nadeem@cadence.com
-
- Feb 08, 2021
-
-
LCPD Auto Merger authored
TI-Feature: rpmsg TI-Branch: rpmsg-ti-linux-5.4.y-intg * 'rpmsg-ti-linux-5.4.y-intg' of git://git.ti.com/rpmsg/rpmsg : arm64: dts: ti: k3-am642-sk: Reserve some on-chip SRAM for R5Fs arm64: dts: ti: k3-am642-sk: Reserve memory for IPC between RTOS cores arm64: dts: ti: k3-am642-sk: Add DDR carveout memory nodes for R5Fs arm64: dts: ti: k3-am642-sk: Add mailboxes to R5Fs arm64: dts: ti: k3-am642-sk: Add IPC sub-mailbox nodes Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
Suman Anna authored
Reserve some portions of the MAIN domain on-chip SRAM for use by various R5F cores on AM642 SK board. A bank (256 KB) each is reserved from the on-chip SRAM for each R5F core. This is done through specific child SRAM nodes in the board dts file. The memory regions are also assigned to each R5F remoteproc node using the sram property. The reserved SRAM banks are as follows for each core: Main R5FSS0 Core0 : OCSRAM1 Main R5FSS0 Core1 : OCSRAM2 Main R5FSS1 Core0 : OCSRAM3 Main R5FSS1 Core1 : OCSRAM4 The addresses chosen are the same as the respective processors on the AM64x EVM board to maintain firmware compatibility between the two boards. Please also see commit d4175486 ("arm64: dts: ti: k3-am642-evm: Reserve some on-chip SRAM for R5Fs"). Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
Add a reserved memory node to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS or baremetal on the TI K3 AM642 SK board. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The reserved memory set aside is the same as the respective carveout on the AM64x EVM board to maintain firmware compatibility between the two boards. Please see commit bfe19680 ("arm64: dts: ti: k3-am642-evm: Reserve memory for IPC between RTOS cores"). Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within the MAIN domain on the TI AM642 SK board. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments. The addresses chosen are the same as the respective processors on the AM64x EVM board to maintain firmware compatibility between the two boards. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non Single-CPU) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
Add the required 'mboxes' property to all the R5F processors on the TI AM642 SK board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the AM64x SoCs for the AM642 SK board. These include the R5F remote processors in the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; and a M4 processor in the MCU safety island. These sub-mailbox nodes utilize the System Mailbox clusters 2, 4 and 6. The remaining clusters 3, 5 and 7 are currently not used, and so are disabled. Clusters 0 and 1 were never added to the dts file as they do not support interrupts towards the A53 core. The sub-mailbox nodes added match the hard-coded mailbox configuration used within the TI RTOS IPC software packages. The R5F processor sub-systems are assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. Only the sub-mailbox node for the first R5F core in each cluster is used in case of a Single-CPU mode for that R5F cluster. The nodes are all identical to those added on the AM64x EVM board to maintain firmware compatibility between the two boards. NOTE: The cluster nodes only have the Mailbox IP interrupt outputs that are routed to the GIC_SPI. The sub-mailbox nodes' irq-id are indexing into the listed interrupts, with the usr-id using the actual interrupt output line number from the Mailbox IP. Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : usb: cdns3: Add support for TI's AM64 SoC arm64: dts: ti: k3-j7200-main: Remove sdhci-caps-mask to add support for SDR104 mode in MMCSD1 subsystem arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes in MMCSD0 subsystem net: ethernet: ti: cpsw: fix crash in dual_emac mode with one ext port Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
- Feb 07, 2021
-
-
Add support for USB controller present on the AM64x SoC. Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
arm64: dts: ti: k3-j7200-main: Remove sdhci-caps-mask to add support for SDR104 mode in MMCSD1 subsystem Remove sdhci-caps-mask property as SDR104 speed mode is now supported in MMCSD1 subsystem of J7200 SoC[1]. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
HS200 and HS400 modes at 1.8 V card voltage, are now supported in MMCSD0 subsystem of J7200 SoC[1]. Set respective tags to indicate it. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
The CPSW driver will crash with NULL pointer exception in dual_emac mode when there is only one ext. port physically connected and DT property "slaves" set to <1>. Fix crash, by adding missing check to prevent creating second netdev when "slaves = <1>". Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
- Feb 05, 2021
-
-
LCPD Auto Merger authored
TI-Feature: platform_base TI-Branch: platform-ti-linux-5.4.y * 'platform-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform : arm64: dts: ti: Add support for AM642 SK dt-bindings: arm: ti: Add bindings for AM642 SK Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com>
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. Add DT binding documentation for AM642 SK. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com>
-
- Feb 03, 2021
-
-
Dan Murphy authored
Merge tag 'v5.4.93' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-5.4.y This is the 5.4.93 stable release * tag 'v5.4.93' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (122 commits) Linux 5.4.93 tcp: fix TCP_USER_TIMEOUT with zero window tcp: do not mess with cloned skbs in tcp_add_backlog() net: dsa: b53: fix an off by one in checking "vlan->vid" net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled net: mscc: ocelot: allow offloading of bridge on top of LAG ipv6: set multicast flag on the multicast route net_sched: reject silly cell_log in qdisc_get_rtab() net_sched: avoid shift-out-of-bounds in tcindex_set_parms() ipv6: create multicast route with RTPROT_KERNEL udp: mask TOS bits in udp_v4_early_demux() kasan: fix incorrect arguments passing in kasan_add_zero_shadow kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too lightnvm:...
-
- Jan 27, 2021
-
-
Greg Kroah-Hartman authored
Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20210126111748.320806573@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Enke Chen authored
commit 9d9b1ee0 upstream. The TCP session does not terminate with TCP_USER_TIMEOUT when data remain untransmitted due to zero window. The number of unanswered zero-window probes (tcp_probes_out) is reset to zero with incoming acks irrespective of the window size, as described in tcp_probe_timer(): RFC 1122 4.2.2.17 requires the sender to stay open indefinitely as long as the receiver continues to respond probes. We support this by default and reset icsk_probes_out with incoming ACKs. This counter, however, is the wrong one to be used in calculating the duration that the window remains closed and data remain untransmitted. Thanks to Jonathan Maxwell <jmaxwell37@gmail.com> for diagnosing the actual issue. In this patch a new timestamp is introduced for the socket in order to track the elapsed time for the zero-window probes that have not been answered with any non-zero window ack. Fixes: 9721e709 ("tcp: simplify window probe aborting on USER_TIMEOUT") Reported-by:
William McCall <william.mccall@gmail.com> Co-developed-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Enke Chen <enchen@paloaltonetworks.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210115223058.GA39267@localhost.localdomain Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit b160c285 upstream. Heiner Kallweit reported that some skbs were sent with the following invalid GSO properties : - gso_size > 0 - gso_type == 0 This was triggerring a WARN_ON_ONCE() in rtl8169_tso_csum_v2. Juerg Haefliger was able to reproduce a similar issue using a lan78xx NIC and a workload mixing TCP incoming traffic and forwarded packets. The problem is that tcp_add_backlog() is writing over gso_segs and gso_size even if the incoming packet will not be coalesced to the backlog tail packet. While skb_try_coalesce() would bail out if tail packet is cloned, this overwriting would lead to corruptions of other packets cooked by lan78xx, sharing a common super-packet. The strategy used by lan78xx is to use a big skb, and split it into all received packets using skb_clone() to avoid copies. The drawback of this strategy is that all the small skb share a common struct skb_shared_info. This patch rewrites TCP gso_size/gso_segs handling to only happen on the tail skb, since skb_try_coalesce() made sure it was not cloned. Fixes: 4f693b55 ("tcp: implement coalescing on backlog queue") Signed-off-by:
Eric Dumazet <edumazet@google.com> Bisected-by:
Juerg Haefliger <juergh@canonical.com> Tested-by:
Juerg Haefliger <juergh@canonical.com> Reported-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209423 Link: https://lore.kernel.org/r/20210119164900.766957-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
commit 8e4052c3 upstream. The > comparison should be >= to prevent accessing one element beyond the end of the dev->vlans[] array in the caller function, b53_vlan_add(). The "dev->vlans" array is allocated in the b53_switch_init() function and it has "dev->num_vlans" elements. Fixes: a2482d2c ("net: dsa: b53: Plug in VLAN support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tariq Toukan authored
commit a3eb4e9d upstream. With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be logically done when RXCSUM offload is off. Fixes: 14136564 ("net: Add TLS RX offload feature") Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Link: https://lore.kernel.org/r/20210117151538.9411-1-tariqt@nvidia.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vladimir Oltean authored
commit 79267ae2 upstream. The blamed commit was too aggressive, and it made ocelot_netdevice_event react only to network interface events emitted for the ocelot switch ports. In fact, only the PRECHANGEUPPER should have had that check. When we ignore all events that are not for us, we miss the fact that the upper of the LAG changes, and the bonding interface gets enslaved to a bridge. This is an operation we could offload under certain conditions. Fixes: 7afb3e57 ("net: mscc: ocelot: don't handle netdev events for other netdevs") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210118135210.2666246-1-olteanv@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matteo Croce authored
commit ceed9038 upstream. The multicast route ff00::/8 is created with type RTN_UNICAST: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto kernel scope global metric 256 pref medium Set the type to RTN_MULTICAST which is more appropriate. Fixes: e8478e80 ("net/ipv6: Save route type in rt6_info") Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit e4bedf48 upstream. iproute2 probably never goes beyond 8 for the cell exponent, but stick to the max shift exponent for signed 32bit. UBSAN reported: UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22 shift exponent 130 is too large for 32-bit type 'int' CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x183/0x22e lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395 __detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389 qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435 cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180 qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246 tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662 rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x5a2/0x900 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x319/0x400 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit bcd0cf19 upstream. tc_index being 16bit wide, we need to check that TCA_TCINDEX_SHIFT attribute is not silly. UBSAN: shift-out-of-bounds in net/sched/cls_tcindex.c:260:29 shift exponent 255 is too large for 32-bit type 'int' CPU: 0 PID: 8516 Comm: syz-executor228 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 valid_perfect_hash net/sched/cls_tcindex.c:260 [inline] tcindex_set_parms.cold+0x1b/0x215 net/sched/cls_tcindex.c:425 tcindex_change+0x232/0x340 net/sched/cls_tcindex.c:546 tc_new_tfilter+0x13fb/0x21b0 net/sched/cls_api.c:2127 rtnetlink_rcv_msg+0x8b6/0xb80 net/core/rtnetlink.c:5555 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2336 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20210114185229.1742255-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matteo Croce authored
commit a826b043 upstream. The ff00::/8 multicast route is created without specifying the fc_protocol field, so the default RTPROT_BOOT value is used: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium As the documentation says, this value identifies routes installed during boot, but the route is created when interface is set up. Change the value to RTPROT_KERNEL which is a better value. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guillaume Nault authored
commit 8d2b51b0 upstream. udp_v4_early_demux() is the only function that calls ip_mc_validate_source() with a TOS that hasn't been masked with IPTOS_RT_MASK. This results in different behaviours for incoming multicast UDPv4 packets, depending on if ip_mc_validate_source() is called from the early-demux path (udp_v4_early_demux) or from the regular input path (ip_route_input_noref). ECN would normally not be used with UDP multicast packets, so the practical consequences should be limited on that side. However, IPTOS_RT_MASK is used to also masks the TOS' high order bits, to align with the non-early-demux path behaviour. Reproducer: Setup two netns, connected with veth: $ ip netns add ns0 $ ip netns add ns1 $ ip -netns ns0 link set dev lo up $ ip -netns ns1 link set dev lo up $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10 peer 192.0.2.11/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11 peer 192.0.2.10/32 dev veth10 In ns0, add route to multicast address 224.0.2.0/24 using source address 198.51.100.10: $ ip -netns ns0 address add 198.51.100.10/32 dev lo $ ip -netns ns0 route add 224.0.2.0/24 dev veth01 src 198.51.100.10 In ns1, define route to 198.51.100.10, only for packets with TOS 4: $ ip -netns ns1 route add 198.51.100.10/32 tos 4 dev veth10 Also activate rp_filter in ns1, so that incoming packets not matching the above route get dropped: $ ip netns exec ns1 sysctl -wq net.ipv4.conf.veth10.rp_filter=1 Now try to receive packets on 224.0.2.11: $ ip netns exec ns1 socat UDP-RECVFROM:1111,ip-add-membership=224.0.2.11:veth10,ignoreeof - In ns0, send packet to 224.0.2.11 with TOS 4 and ECT(0) (that is, tos 6 for socat): $ echo test0 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test0" message is properly received by socat in ns1, because early-demux has no cached dst to use, so source address validation is done by ip_route_input_mc(), which receives a TOS that has the ECN bits masked. Now send another packet to 224.0.2.11, still with TOS 4 and ECT(0): $ echo test1 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test1" message isn't received by socat in ns1, because, now, early-demux has a cached dst to use and calls ip_mc_validate_source() immediately, without masking the ECN bits. Fixes: bc044e8d ("udp: perform source validation for mcast early demux") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lecopzer Chen authored
commit 5dabd171 upstream. kasan_remove_zero_shadow() shall use original virtual address, start and size, instead of shadow address. Link: https://lkml.kernel.org/r/20210103063847.5963-1-lecopzer@gmail.com Fixes: 0207df4f ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by:
Lecopzer Chen <lecopzer.chen@mediatek.com> Reviewed-by:
Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lecopzer Chen authored
commit a11a496e upstream. During testing kasan_populate_early_shadow and kasan_remove_zero_shadow, if the shadow start and end address in kasan_remove_zero_shadow() is not aligned to PMD_SIZE, the remain unaligned PTE won't be removed. In the test case for kasan_remove_zero_shadow(): shadow_start: 0xffffffb802000000, shadow end: 0xffffffbfbe000000 3-level page table: PUD_SIZE: 0x40000000 PMD_SIZE: 0x200000 PAGE_SIZE: 4K 0xffffffbf80000000 ~ 0xffffffbfbdf80000 will not be removed because in kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next address is 0xffffffbfbdf80000 which is not aligned to PUD_SIZE. In the correct condition, this should fallback to the next level kasan_remove_pmd_table() but the condition flow always continue to skip the unaligned part. Fix by correcting the condition when next and addr are neither aligned. Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecopzer@gmail.com Fixes: 0207df4f ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by:
Lecopzer Chen <lecopzer.chen@mediatek.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: YJ Chiang <yj.chiang@mediatek.com> Cc: Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexander Lobakin authored
commit 66c55602 upstream. Commit 3226b158 ("net: avoid 32 x truesize under-estimation for tiny skbs") ensured that skbs with data size lower than 1025 bytes will be kmalloc'ed to avoid excessive page cache fragmentation and memory consumption. However, the fix adressed only __napi_alloc_skb() (primarily for virtio_net and napi_get_frags()), but the issue can still be achieved through __netdev_alloc_skb(), which is still used by several drivers. Drivers often allocate a tiny skb for headers and place the rest of the frame to frags (so-called copybreak). Mirror the condition to __netdev_alloc_skb() to handle this case too. Since v1 [0]: - fix "Fixes:" tag; - refine commit message (mention copybreak usecase). [0] https://lore.kernel.org/netdev/20210114235423.232737-1-alobakin@pm.me Fixes: a1c7fff7 ("net: netdev_alloc_skb() use build_skb()") Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Link: https://lore.kernel.org/r/20210115150354.85967-1-alobakin@pm.me Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pan Bian authored
commit 97784481 upstream. The allocated page is not released if error occurs in nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid possible memory leak issue. Fixes: aff3fb18 ("lightnvm: move bad block and chunk state logic to core") Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
commit f6a2e94b upstream. sh_eth_close() does a synchronous power down of the device before marking it closed. Revert the order, to make sure the device is never marked opened while suspended. While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as there is no reason to do a synchronous power down. Fixes: 7fa2955f ("sh_eth: Fix sleeping function called from invalid context") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Sergei Shtylyov <sergei.shtylyov@gmail.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rasmus Villemoes authored
commit 87fe0436 upstream. mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069 (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Tobias Waldekranz <tobias@waldekranz.com> Tested-by:
Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Necip Fazil Yildiran authored
commit f477a538 upstream. When G2_DMA is enabled and SH_DMA is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SH_DMA_API Depends on [n]: SH_DMA [=n] Selected by [y]: - G2_DMA [=y] && SH_DREAMCAST [=y] The reason is that G2_DMA selects SH_DMA_API without depending on or selecting SH_DMA while SH_DMA_API depends on SH_DMA. When G2_DMA was first introduced with commit 40f49e7e ("sh: dma: Make G2 DMA configurable."), this wasn't an issue since SH_DMA_API didn't have such dependency, and this way was the only way to enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was made visible and dependent on SH_DMA with commit d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver"). Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues. Fixes: d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver") Signed-off-by: Necip Faz...
-
Guillaume Nault authored
commit 2e5a6266 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip netns add ns0 $ ip netns add ns1 $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11/32 dev veth10 Add a route to ns1 in ns0: $ ip -netns ns0 route add 192.0.2.11/32 dev veth01 In ns1, only packets with TOS 4 can be routed to ns0: $ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS is 4: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ...
-
Yazen Ghannam authored
commit 76e2fc63 upstream. Set the maximum DIE per package variable on AMD using the NodesPerProcessor topology value. This will be used by RAPL, among others, to determine the maximum number of DIEs on the system in order to do per-DIE manipulations. [ bp: Productize into a proper patch. ] Fixes: 028c221e ("x86/CPU/AMD: Save AMD NodeId as cpu_die_id") Reported-by:
Johnathan Smithinovic <johnathan.smithinovic@gmx.at> Reported-by:
Rafael Kitover <rkitover@gmail.com> Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Johnathan Smithinovic <johnathan.smithinovic@gmx.at> Tested-by:
Rafael Kitover <rkitover@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=210939 Link: https://lkml.kernel.org/r/20210106112106.GE5729@zn.tnic Link: https://lkml.kernel.org/r/20210111101455.1194-1-bp@alien8.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul Cercueil authored
commit 9a85c09a upstream. - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and don't use the new register layout, which was introduced with the JZ4770 SoC and not the JZ4760 or JZ4760B SoCs. - The JZ4740 code path only expected two function modes to be configurable for each pin, and wouldn't work with more than two. Fix it for the JZ4760, which has four configurable function modes. Fixes: 0257595a ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.") Cc: <stable@vger.kernel.org> # 5.3 Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-