aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-09i40e: avoid premature Rx buffer reuseBjörn Töpel1-7/+20
The page recycle code, incorrectly, relied on that a page fragment could not be freed inside xdp_do_redirect(). This assumption leads to that page fragments that are used by the stack/XDP redirect can be reused and overwritten. To avoid this, store the page count prior invoking xdp_do_redirect(). Longer explanation: Intel NICs have a recycle mechanism. The main idea is that a page is split into two parts. One part is owned by the driver, one part might be owned by someone else, such as the stack. t0: Page is allocated, and put on the Rx ring +--------------- used by NIC ->| upper buffer (rx_buffer) +--------------- | lower buffer +--------------- page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX t1: Buffer is received, and passed to the stack (e.g.) +--------------- | upper buff (skb) +--------------- used by NIC ->| lower buffer (rx_buffer) +--------------- page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX - 1 t2: Buffer is received, and redirected +--------------- | upper buff (skb) +--------------- used by NIC ->| lower buffer (rx_buffer) +--------------- Now, prior calling xdp_do_redirect(): page count == USHRT_MAX rx_buffer->pagecnt_bias == USHRT_MAX - 2 This means that buffer *cannot* be flipped/reused, because the skb is still using it. The problem arises when xdp_do_redirect() actually frees the segment. Then we get: page count == USHRT_MAX - 1 rx_buffer->pagecnt_bias == USHRT_MAX - 2 From a recycle perspective, the buffer can be flipped and reused, which means that the skb data area is passed to the Rx HW ring! To work around this, the page count is stored prior calling xdp_do_redirect(). Note that this is not optimal, since the NIC could actually reuse the "lower buffer" again. However, then we need to track whether XDP_REDIRECT consumed the buffer or not. Fixes: d9314c474d4f ("i40e: add support for XDP_REDIRECT") Reported-and-analyzed-by: Li RongQing <[email protected]> Signed-off-by: Björn Töpel <[email protected]> Tested-by: George Kuruvinakunnel <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: avoid transmit queue timeout in xdp pathSven Auhagen1-0/+5
Since we share the transmit queue with the network stack, it is possible that we run into a transmit queue timeout. This will reset the queue. This happens under high load when XDP is using the transmit queue pretty much exclusively. netdev_start_xmit() sets the trans_start variable of the transmit queue to jiffies which is later utilized by dev_watchdog(), so to avoid timeout, let stack know that XDP xmit happened by bumping the trans_start within XDP Tx routines to jiffies. Fixes: 9cbc948b5a20 ("igb: add XDP support") Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: use xdp_do_flushSven Auhagen1-1/+1
Since it is a new XDP implementation change xdp_do_flush_map to xdp_do_flush. Fixes: 9cbc948b5a20 ("igb: add XDP support") Suggested-by: Maciej Fijalkowski <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: skb add metasize for xdpSven Auhagen1-0/+4
add metasize if it is set in xdp Fixes: 9cbc948b5a20 ("igb: add XDP support") Suggested-by: Maciej Fijalkowski <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: XDP extack message on errorSven Auhagen1-5/+12
Add an extack error message when the RX buffer size is too small for the frame size. Fixes: 9cbc948b5a20 ("igb: add XDP support") Suggested-by: Maciej Fijalkowski <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: take VLAN double header into accountSven Auhagen2-4/+8
Increase the packet header padding to include double VLAN tagging. This patch uses a macro for this. Fixes: 9cbc948b5a20 ("igb: add XDP support") Suggested-by: Maciej Fijalkowski <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09igb: XDP xmit back fix error codeSven Auhagen1-1/+1
The igb XDP xmit back function should only return defined error codes. Fixes: 9cbc948b5a20 ("igb: add XDP support") Reported-by: Dan Carpenter <[email protected]> Acked-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Sven Auhagen <[email protected]> Tested-by: Sandeep Penigalapati <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-12-09Merge tag 'arm-soc-fixes-v5.10-4b' of ↵Linus Torvalds16-24/+30
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "There are a few more PHY mode changes for allwinner SoC based boards with a Realtek PHY after the driver changed its behavior, I assume there will be more of these in the future. Also on for Allwinner, the Banana Pi M2 board had a regression that led to some devices not working because of a slightly incorrect voltage being applied. By popular demand, I picked up a change from Krzysztof Kozlowski to actually list the SoC tree in the MAINTAINERS file. We don't want to get Cc'd on normal patches that are picked up by platform maintainers, but the lack of an entry has led to confusion in the past. All the other changes are fairly benign, fixing boot-time or compile-time warning messages in various places: - A dtc warning on the OLPC XO-1.75 - A boot-time warning on i.MX6 wandboard - A harmless compile-time warning - A regression causing one of the i.MX6 SoCs to be identified as another - Missing SoC identification of Allwinner V3 and S3" * tag 'arm-soc-fixes-v5.10-4b' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: firmware: xilinx: Mark pm_api_features_map with static keyword ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs MAINTAINERS: add a limited ARM and ARM64 SoC entry MAINTAINERS: correct SoC Git address (formerly: arm-soc) ARM: keystone: remove SECTION_SIZE_BITS/MAX_PHYSMEM_BITS arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode rgmii-id arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id ARM: dts: imx6qdl-kontron-samx6i: fix I2C_PM scl pin ARM: dts: imx6qdl-wandboard-revd1: Remove PAD_GPIO_6 from enetgrp ARM: imx: Use correct SRC base address ARM: dts: sun7i: pcduino3-nano: enable RGMII RX/TX delay on PHY ARM: dts: sun8i: v3s: fix GIC node memory range ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY ARM: dts: s3: pinecube: align compatible property to other S3 boards ARM: sunxi: Add machine match for the Allwinner V3 SoC arm64: dts: allwinner: h6: orangepi-one-plus: Fix ethernet
2020-12-09Revert "geneve: pull IP header before ECN decapsulation"Jakub Kicinski1-16/+4
This reverts commit 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation"). Eric says: "network header should have been pulled already before hitting geneve_rx()". Let's revert the syzbot fix since it's causing more harm than good, and revisit. Suggested-by: Eric Dumazet <[email protected]> Reported-by: Jianlin Shi <[email protected]> Fixes: 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation") Link: https://bugzilla.kernel.org/show_bug.cgi?id=210569 Link: https://lore.kernel.org/netdev/CANn89iJVWfb=2i7oU1=D55rOyQnBbbikf+Mc6XHMkY7YX-yGEw@mail.gmail.com/ Signed-off-by: Jakub Kicinski <[email protected]>
2020-12-09firmware: xilinx: Mark pm_api_features_map with static keywordZou Wei1-1/+1
Fix the following sparse warning: drivers/firmware/xilinx/zynqmp.c:32:1: warning: symbol 'pm_api_features_map' was not declared. Should it be static? Signed-off-by: Zou Wei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2020-12-09ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbsZhen Lei1-2/+1
The check_spi_bus_bridge() in scripts/dtc/checks.c requires that the node have "spi-slave" property must with "#address-cells = <0>" and "#size-cells = <0>". But currently both "#address-cells" and "#size-cells" properties are deleted, the corresponding default values are 2 and 1. As a result, the check fails and below warnings is displayed. arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): \ /soc/apb@d4000000/spi@d4037000: incorrect #address-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): \ /soc/apb@d4000000/spi@d4037000: incorrect #size-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dtb: Warning (spi_bus_reg): \ Failed prerequisite 'spi_bus_bridge' Because the value of "#size-cells" is already defined as zero in the node "ssp3: spi@d4037000" in arch/arm/boot/dts/mmp2.dtsi. So we only need to explicitly add "#address-cells = <0>" and keep "#size-cells" no change. Signed-off-by: Zhen Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected]' Signed-off-by: Arnd Bergmann <[email protected]>
2020-12-09RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewaitLeon Romanovsky1-0/+2
If cm_create_timewait_info() fails, the timewait_info pointer will contain an error value and will be used in cm_remove_remote() later. general protection fault, probably for non-canonical address 0xdffffc0000000024: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0×0000000000000120-0×0000000000000127] CPU: 2 PID: 12446 Comm: syz-executor.3 Not tainted 5.10.0-rc5-5d4c0742a60e #27 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:cm_remove_remote.isra.0+0x24/0×170 drivers/infiniband/core/cm.c:978 Code: 84 00 00 00 00 00 41 54 55 53 48 89 fb 48 8d ab 2d 01 00 00 e8 7d bf 4b fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 48 89 ea 83 e2 07 38 d0 7f 08 84 c0 0f 85 fc 00 00 00 RSP: 0018:ffff888013127918 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: ffffc9000a18b000 RDX: 0000000000000024 RSI: ffffffff82edc573 RDI: fffffffffffffff4 RBP: 0000000000000121 R08: 0000000000000001 R09: ffffed1002624f1d R10: 0000000000000003 R11: ffffed1002624f1c R12: ffff888107760c70 R13: ffff888107760c40 R14: fffffffffffffff4 R15: ffff888107760c9c FS: 00007fe1ffcc1700(0000) GS:ffff88811a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2ff21000 CR3: 000000010f504001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: cm_destroy_id+0x189/0×15b0 drivers/infiniband/core/cm.c:1155 cma_connect_ib drivers/infiniband/core/cma.c:4029 [inline] rdma_connect_locked+0x1100/0×17c0 drivers/infiniband/core/cma.c:4107 rdma_connect+0x2a/0×40 drivers/infiniband/core/cma.c:4140 ucma_connect+0x277/0×340 drivers/infiniband/core/ucma.c:1069 ucma_write+0x236/0×2f0 drivers/infiniband/core/ucma.c:1724 vfs_write+0x220/0×830 fs/read_write.c:603 ksys_write+0x1df/0×240 fs/read_write.c:658 do_syscall_64+0x33/0×40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation") Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Maor Gottlieb <[email protected]> Reported-by: Amit Matityahu <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-12-09Merge tag 'iommu-fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull iommu fix from Will Deacon: "Fix interrupt table length definition for AMD IOMMU. It's actually a fix for a fix, where the size of the interrupt remapping table was increased but a related constant for the size of the interrupt table was forgotten" * tag 'iommu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
2020-12-09can: isotp: isotp_setsockopt(): block setsockopt on bound socketsOliver Hartkopp1-0/+3
The isotp socket can be widely configured in its behaviour regarding addressing types, fill-ups, receive pattern tests and link layer length. Usually all these settings need to be fixed before bind() and can not be changed afterwards. This patch adds a check to enforce the common usage pattern. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Signed-off-by: Oliver Hartkopp <[email protected]> Tested-by: Thomas Wagner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-12-09Merge branch 'bpf-xdp-offload-fixes'Daniel Borkmann8-54/+60
Toke Høiland-Jørgensen says: ==================== This series restores the test_offload.py selftest to working order. It seems a number of subtle behavioural changes have crept into various subsystems which broke test_offload.py in a number of ways. Most of these are fairly benign changes where small adjustments to the test script seems to be the best fix, but one is an actual kernel bug that I've observed in the wild caused by a bad interaction between xdp_attachment_flags_ok() and the rework of XDP program handling in the core netdev code. Patch 1 fixes the bug by removing xdp_attachment_flags_ok(), and the reminder of the patches are adjustments to test_offload.py, including a new feature for netdevsim to force a BPF verification fail. Please see the individual patches for details. Changelog: v4: - Accidentally truncated the Fixes: hashes in patches 3/4 to 11 chars v3: - Add Fixes: tags v2: - Replace xdp_attachment_flags_ok() with a check in dev_xdp_attach() - Better packing of struct nsim_dev ==================== Signed-off-by: Daniel Borkmann <[email protected]>
2020-12-09selftests/bpf/test_offload.py: Filter bpftool internal map when counting mapsToke Høiland-Jørgensen1-3/+4
A few of the tests in test_offload.py expects to see a certain number of maps created, and checks this by counting the number of maps returned by bpftool. There is already a filter that will remove any maps already there at the beginning of the test, but bpftool now creates a map for the PID iterator rodata on each invocation, which makes the map count wrong. Fix this by also filtering the pid_iter.rodata map by name when counting. Fixes: d53dee3fe013 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09selftests/bpf/test_offload.py: Reset ethtool features after failed settingToke Høiland-Jørgensen1-0/+1
When setting the ethtool feature flag fails (as expected for the test), the kernel now tracks that the feature was requested to be 'off' and refuses to subsequently disable it again. So reset it back to 'on' so a subsequent disable (that's not supposed to fail) can succeed. Fixes: 417ec26477a5 ("selftests/bpf: add offload test based on netdevsim") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09selftests/bpf/test_offload.py: Fix expected case of extack messagesToke Høiland-Jørgensen1-2/+2
Commit 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device") changed the case of some of the extack messages being returned when attaching of XDP programs failed. This broke test_offload.py, so let's fix the test to reflect this. Fixes: 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09selftests/bpf/test_offload.py: Only check verifier log on verification failsToke Høiland-Jørgensen1-2/+17
Since commit 6f8a57ccf851 ("bpf: Make verifier log more relevant by default"), the verifier discards log messages for successfully-verified programs. This broke test_offload.py which is looking for a verification message from the driver callback. Change test_offload.py to use the toggle in netdevsim to make the verification fail before looking for the verification message. Fixes: 6f8a57ccf851 ("bpf: Make verifier log more relevant by default") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09netdevsim: Add debugfs toggle to reject BPF programs in verifierToke Høiland-Jørgensen2-2/+11
This adds a new debugfs toggle ('bpf_bind_verifier_accept') that can be used to make netdevsim reject BPF programs from being accepted by the verifier. If this toggle (which defaults to true) is set to false, nsim_bpf_verify_insn() will return EOPNOTSUPP on the last instruction (after outputting the 'Hello from netdevsim' verifier message). This makes it possible to check the verification callback in the driver from test_offload.py in selftests, since the verifier now clears the verifier log on a successful load, hiding the message from the driver. Fixes: 6f8a57ccf851 ("bpf: Make verifier log more relevant by default") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09selftests/bpf/test_offload.py: Remove check for program load flags matchToke Høiland-Jørgensen1-17/+5
Since we just removed the xdp_attachment_flags_ok() callback, also remove the check for it in test_offload.py, and replace it with a test for the new ambiguity-avoid check when multiple programs are loaded. Fixes: 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09xdp: Remove the xdp_attachment_flags_ok() callbackToke Høiland-Jørgensen6-28/+20
Since commit 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device"), the XDP program attachment info is now maintained in the core code. This interacts badly with the xdp_attachment_flags_ok() check that prevents unloading an XDP program with different load flags than it was loaded with. In practice, two kinds of failures are seen: - An XDP program loaded without specifying a mode (and which then ends up in driver mode) cannot be unloaded if the program mode is specified on unload. - The dev_xdp_uninstall() hook always calls the driver callback with the mode set to the type of the program but an empty flags argument, which means the flags_ok() check prevents the program from being removed, leading to bpf prog reference leaks. The original reason this check was added was to avoid ambiguity when multiple programs were loaded. With the way the checks are done in the core now, this is quite simple to enforce in the core code, so let's add a check there and get rid of the xdp_attachment_flags_ok() callback entirely. Fixes: 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device") Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-09drm/amdgpu: Initialise drm_gem_object_funcs for imported BOsAndrey Grodzovsky2-20/+29
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation and amdgpu_gem_object_funcs setting into single function called from both code paths. Fixes: d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver") v2: Use use amdgpu_gem_object_create() directly v3: fix warning Reviewed-by: Christian König <[email protected]> Signed-off-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-12-09drm/amdgpu: fix size calculation with stolen vga memoryAlex Deucher1-0/+3
If we need to keep the stolen vga memory, make sure it is at least as big as the legacy vga size. Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-12-09drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for ravenChangfeng2-14/+9
When using old WORKLOAD_PPLIB setting in smu10.h, there is problem that it can't be able to switch to mak gpu clk during compute workload. It needs to update WORKLOAD_PPLIB setting to fix this issue. Signed-off-by: Changfeng <[email protected]> Reviewed-by: Huang Rui <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-12-09drm/amdkfd: Fix leak in dmabuf importFelix Kuehling1-0/+2
Release dmabuf reference before returning from kfd_ioctl_import_dmabuf. amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying GEM BO and doesn't keep the reference to the dmabuf wrapper. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-12-09drm/amdgpu: fix sdma instance fw version and feature version initStanley.Yang1-1/+1
each sdma instance fw_version and feature_version should be set right value when asic type isn't between SIENNA_CICHILD and CHIP_DIMGREY_CAVEFISH Signed-off-by: Stanley.Yang <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-12-09drm/amd/display: Add wm table for RenoirSung Lee1-4/+89
[Why] Without additional HostVM Latency, Renoir takes 2us longer to exit self-refresh. This causes underflow in certain cases. [How] Add table for Renoir with updated sr exit latencies for WM set A. Signed-off-by: Sung Lee <[email protected]> Reviewed-by: Yongqiang Sun <[email protected]> Reviewed-by: Roman Li <[email protected]> Acked-by: Eryk Brol <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-12-09drm/amd/display: Prevent bandwidth overflowChris Park1-2/+5
[Why] At very high pixel clock, bandwidth calculation exceeds 32 bit size and overflow value. This causes the resulting selection of link rate to be inaccurate. [How] Change order of operation and use fixed point to deal with integer accuracy. Also address bug found when forcing link rate. Signed-off-by: Chris Park <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Eryk Brol <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-12-09drm/amdgpu: fix debugfs creation/removal, againArnd Bergmann2-14/+5
There is still a warning when CONFIG_DEBUG_FS is disabled: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error: 'amdgpu_ras_debugfs_create_ctrl_node' defined but not used [-Werror=unused-function] 1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev) Change the code again to make the compiler actually drop this code but not warn about it. Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based on CONFIG_DEBUG_FS") Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-12-09drm/amdgpu/disply: set num_crtc earlierAlex Deucher1-5/+4
To avoid a recently added warning: Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc mask=0x7) WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200 [drm] In this case the warning is harmless, but confusing to users. Fixes: 0df108237433 ("drm: Validate encoder->possible_crtcs") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209123 Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-12-09netfilter: nft_ct: Remove confirmation check for NFT_CT_IDBrett Mastbergen1-2/+0
Since commit 656c8e9cc1ba ("netfilter: conntrack: Use consistent ct id hash calculation") the ct id will not change from initialization to confirmation. Removing the confirmation check allows for things like adding an element to a 'typeof ct id' set in prerouting upon reception of the first packet of a new connection, and then being able to reference that set consistently both before and after the connection is confirmed. Fixes: 656c8e9cc1ba ("netfilter: conntrack: Use consistent ct id hash calculation") Signed-off-by: Brett Mastbergen <[email protected]> Acked-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-12-09xen: don't use page->lru for ZONE_DEVICE memoryJuergen Gross3-16/+73
Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen backend private page caches. Fix that by using page->zone_device_data instead. Cc: <[email protected]> # 5.9 Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Jason Andryuk <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2020-12-09xen: add helpers for caching grant mapping pagesJuergen Gross6-128/+116
Instead of having similar helpers in multiple backend drivers use common helpers for caching pages allocated via gnttab_alloc_pages(). Make use of those helpers in blkback and scsiback. Cc: <[email protected]> # 5.9 Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2020-12-09gpio: eic-sprd: break loop when getting NULL device resourceChunyan Zhang1-1/+1
EIC controller have unfixed numbers of banks on different Spreadtrum SoCs, and each bank has its own base address, the loop of getting there base address in driver should break if the resource gotten via platform_get_resource() is NULL already. The later ones would be all NULL even if the loop continues. Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support") Signed-off-by: Chunyan Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-12-09membarrier: Execute SYNC_CORE on the calling threadAndy Lutomirski1-18/+33
membarrier()'s MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE is documented as syncing the core on all sibling threads but not necessarily the calling thread. This behavior is fundamentally buggy and cannot be used safely. Suppose a user program has two threads. Thread A is on CPU 0 and thread B is on CPU 1. Thread A modifies some text and calls membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE). Then thread B executes the modified code. If, at any point after membarrier() decides which CPUs to target, thread A could be preempted and replaced by thread B on CPU 0. This could even happen on exit from the membarrier() syscall. If this happens, thread B will end up running on CPU 0 without having synced. In principle, this could be fixed by arranging for the scheduler to issue sync_core_before_usermode() whenever switching between two threads in the same mm if there is any possibility of a concurrent membarrier() call, but this would have considerable overhead. Instead, make membarrier() sync the calling CPU as well. As an optimization, this avoids an extra smp_mb() in the default barrier-only mode and an extra rseq preempt on the caller. Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/r/250ded637696d490c69bef1877148db86066881c.1607058304.git.luto@kernel.org
2020-12-09membarrier: Explicitly sync remote cores when SYNC_CORE is requestedAndy Lutomirski1-0/+18
membarrier() does not explicitly sync_core() remote CPUs; instead, it relies on the assumption that an IPI will result in a core sync. On x86, this may be true in practice, but it's not architecturally reliable. In particular, the SDM and APM do not appear to guarantee that interrupt delivery is serializing. While IRET does serialize, IPI return can schedule, thereby switching to another task in the same mm that was sleeping in a syscall. The new task could then SYSRET back to usermode without ever executing IRET. Make this more robust by explicitly calling sync_core_before_usermode() on remote cores. (This also helps people who search the kernel tree for instances of sync_core() and sync_core_before_usermode() -- one might be surprised that the core membarrier code doesn't currently show up in a such a search.) Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/776b448d5f7bd6b12690707f5ed67bcda7f1d427.1607058304.git.luto@kernel.org
2020-12-09membarrier: Add an actual barrier before rseq_preempt()Andy Lutomirski1-0/+8
It seems that most RSEQ membarrier users will expect any stores done before the membarrier() syscall to be visible to the target task(s). While this is extremely likely to be true in practice, nothing actually guarantees it by a strict reading of the x86 manuals. Rather than providing this guarantee by accident and potentially causing a problem down the road, just add an explicit barrier. Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/d3e7197e034fa4852afcf370ca49c30496e58e40.1607058304.git.luto@kernel.org
2020-12-09x86/membarrier: Get rid of a dubious optimizationAndy Lutomirski2-6/+13
sync_core_before_usermode() had an incorrect optimization. If the kernel returns from an interrupt, it can get to usermode without IRET. It just has to schedule to a different task in the same mm and do SYSRET. Fortunately, there were no callers of sync_core_before_usermode() that could have had in_irq() or in_nmi() equal to true, because it's only ever called from the scheduler. While at it, clarify a related comment. Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/5afc7632be1422f91eaf7611aaaa1b5b8580a086.1607058304.git.luto@kernel.org
2020-12-09pinctrl: intel: Actually disable Tx and Rx buffers on GPIO requestAndy Shevchenko1-2/+2
Mistakenly the buffers (input and output) become enabled together for a short period of time during GPIO request. This is problematic, because instead of initial motive to disable them in the commit af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO"), the driven value on the pin, which might be used as an IRQ line, brings firmwares of some touch pads to an awkward state that needs a full power off to recover. Fix this, as stated in the culprit commit, by disabling the buffers. Fixes: af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210497 Reported-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Tested-by: Pierre-Louis Bossart <[email protected]> Tested-by: Kai-Heng Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-12-08mm/madvise: remove racy mm ownership checkMinchan Kim1-2/+1
Jann spotted the security hole due to race of mm ownership check. If the task is sharing the mm_struct but goes through execve() before mm_access(), it could skip process_madvise_behavior_valid check. That makes *any advice hint* to reach into the remote process. This patch removes the mm ownership check. With it, it will lose the ability that local process could give *any* advice hint with vector interface for some reason (e.g., performance). Since there is no concrete example in upstream yet, it would be better to remove the abiliity at this moment and need to review when such new advice comes up. Fixes: ecb8ac8b1f14 ("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") Reported-by: Jann Horn <[email protected]> Suggested-by: Jann Horn <[email protected]> Signed-off-by: Minchan Kim <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-08drm/amdgpu/powerplay: parse fan table for CI asicsAlex Deucher1-1/+102
Set up all the parameters required for SMU fan control if supported. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=201539 Acked-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-12-08bpf, doc: Update KP's email in MAINTAINERSKP Singh1-2/+2
Helps me use a single account to sign off and send patches use appropriate email redirection without needing to update MAINTAINERS. Signed-off-by: KP Singh <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-12-08tcp: select sane initial rcvq_space.space for big MSSEric Dumazet1-1/+2
Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB") small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate various MSS. This is no longer the case, and Hazem Mohamed Abuelfotoh reported that DRS would not work for MTU 9000 endpoints receiving regular (1500 bytes) frames. Root cause is that tcp_init_buffer_space() uses tp->rcv_wnd for upper limit of rcvq_space.space computation, while it can select later a smaller value for tp->rcv_ssthresh and tp->window_clamp. ss -temoi on receiver would show : skmem:(r0,rb131072,t0,tb46080,f0,w0,o0,bl0,d0) rcv_space:62496 rcv_ssthresh:56596 This means that TCP can not increase its window in tcp_grow_window(), and that DRS can never kick. Fix this by making sure that rcvq_space.space is not bigger than number of bytes that can be held in TCP receive queue. People unable/unwilling to change their kernel can work around this issue by selecting a bigger tcp_rmem[1] value as in : echo "4096 196608 6291456" >/proc/sys/net/ipv4/tcp_rmem Based on an initial report and patch from Hazem Mohamed Abuelfotoh https://lore.kernel.org/netdev/[email protected]/ Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB") Fixes: 041a14d26715 ("tcp: start receiver buffer autotuning sooner") Reported-by: Hazem Mohamed Abuelfotoh <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-12-08net: ll_temac: Fix potential NULL dereference in temac_probe()Zhang Changzhong1-6/+3
platform_get_resource() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource() instead of calling platform_get_resource() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: 8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms") Signed-off-by: Zhang Changzhong <[email protected]> Acked-by: Esben Haabendal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-12-08afs: Fix memory leak when mounting with multiple source parametersDavid Howells1-0/+3
There's a memory leak in afs_parse_source() whereby multiple source= parameters overwrite fc->source in the fs_context struct without freeing the previously recorded source. Fix this by only permitting a single source parameter and rejecting with an error all subsequent ones. This was caught by syzbot with the kernel memory leak detector, showing something like the following trace: unreferenced object 0xffff888114375440 (size 32): comm "repro", pid 5168, jiffies 4294923723 (age 569.948s) backtrace: slab_post_alloc_hook+0x42/0x79 __kmalloc_track_caller+0x125/0x16a kmemdup_nul+0x24/0x3c vfs_parse_fs_string+0x5a/0xa1 generic_parse_monolithic+0x9d/0xc5 do_new_mount+0x10d/0x15a do_mount+0x5f/0x8e __do_sys_mount+0xff/0x127 do_syscall_64+0x2d/0x3a entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 13fcc6837049 ("afs: Add fs_context support") Reported-by: [email protected] Signed-off-by: David Howells <[email protected]> cc: Randy Dunlap <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-08net: tipc: prevent possible null deref of linkCengiz Can1-2/+4
`tipc_node_apply_property` does a null check on a `tipc_link_entry` pointer but also accesses the same pointer out of the null check block. This triggers a warning on Coverity Static Analyzer because we're implying that `e->link` can BE null. Move "Update MTU for node link entry" line into if block to make sure that we're not in a state that `e->link` is null. Signed-off-by: Cengiz Can <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-12-09Merge tag 'sunxi-fixes-for-5.10-3' of ↵Arnd Bergmann2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes A few more RGMII-ID fixes * tag 'sunxi-fixes-for-5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode rgmii-id arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id Link: https://lore.kernel.org/r/2a351c9c-470f-4c5e-ba37-80065ae0586d.lettre@localhost Signed-off-by: Arnd Bergmann <[email protected]>
2020-12-08Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds1-1/+1
Pull sparc64 csum fix from Al Viro: "Fix for a brown paperbag regression in sparc64" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: [regression fix] really dumb fuckup in sparc64 __csum_partial_copy() changes
2020-12-08Revert "scsi: megaraid_sas: Added support for shared host tagset for cpuhotplug"Linus Torvalds2-55/+13
This reverts commit 103fbf8e4020845e4fcf63819288cedb092a3c91. It turns out that it causes long boot-time latencies (to the point of timeouts and failed boots). The cause is the increase in request queues, and a fix for that is queued up for 5.11, but we're reverting this commit that triggered the problem for now. Reported-and-tested-by: John Garry <[email protected]> Reported-and-tested-by: Julia Lawall <[email protected]> Reported-by: Qian Cai <[email protected]> Acked-by: Jens Axboe <[email protected]> Acked-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/linux-scsi/[email protected]/ Link: https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2012081813310.2680@hadrien/ Link: https://lore.kernel.org/linux-block/[email protected]/ Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.