aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-20Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski3-6/+6
Daniel Borkmann says: ==================== pull-request: bpf 2021-01-20 1) Fix wrong bpf_map_peek_elem_proto helper callback, from Mircea Cirjaliu. 2) Fix signed_{sub,add32}_overflows type truncation, from Daniel Borkmann. 3) Fix AF_XDP to also clear pools for inactive queues, from Maxim Mikityanskiy. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Fix signed_{sub,add32}_overflows type handling xsk: Clear pool even for inactive queues bpf: Fix helper bpf_map_peek_elem_proto pointing to wrong callback ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-20spi: altera: Fix memory leak on error pathPan Bian1-1/+2
Release master that have been previously allocated if the number of chipselect is invalid. Fixes: 8e04187c1bc7 ("spi: altera: add SPI core parameters support via platform data.") Signed-off-by: Pan Bian <[email protected]> Reviewed-by: Tom Rix <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-01-20ASoC: topology: Fix memory corruption in soc_tplg_denum_create_values()Dan Carpenter1-1/+1
The allocation uses sizeof(u32) when it should use sizeof(unsigned long) so it leads to memory corruption later in the function when the data is initialized. Fixes: 5aebe7c7f9c2 ("ASoC: topology: fix endianness issues") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/YAf+8QZoOv+ct526@mwanda Signed-off-by: Mark Brown <[email protected]>
2021-01-20ASoC: qcom: lpass-ipq806x: fix bitwidth regmap fieldSrinivas Kandagatla1-1/+1
BIT_WIDTH field in I2S_CTL register is two bits wide, however recent regmap field conversion patch trimmed it down to one bit. Fix this by correcting the bit range! Fixes: b5022a36d28f ("ASoC: qcom: lpass: Use regmap_field for i2sctl and dmactl registers") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-01-20ASoC: AMD Renoir - refine DMI entries for some Lenovo productsJaroslav Kysela1-2/+16
Apparently, the DMI board name LNVNB161216 is also used also for products with the digital microphones connected to the AMD's audio bridge. Refine the DMI table - use product name identifiers extracted from https://bugzilla.redhat.com/show_bug.cgi?id=1892115 . The report for Lenovo Yoga Slim 7 14ARE05 (82A2) is in buglink. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211299 Cc: <[email protected]> Signed-off-by: Jaroslav Kysela <[email protected]> Cc: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-01-20ASoC: qcom: Fix broken support to MI2S TERTIARY and QUATERNARYSrinivas Kandagatla4-7/+38
lpass hdmi support patch totally removed support for MI2S TERTIARY and QUATERNARY. One of the major issue was spotted with the design of having separate SoC specific header files for the common lpass driver. This design is prone to break as an when new SoC header is added as the common DAI ids of other SoCs will be overwritten by the new ones. Having a common header qcom,lpass.h should fix the issue and any new DAI ids should be added to the common header. With this change lpass also needs a new of_xlate function to resolve dai name. Fixes: 7cb37b7bd0d3 ("ASoC: qcom: Add support for lpass hdmi driver") Reported-by: Jun Nie <[email protected]> Reported-by: Stephan Gerhold <[email protected]> Tested-by: Srinivasa Rao <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Tested-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-01-20ASoC: dt-bindings: lpass: Fix and common up lpass dai idsSrinivas Kandagatla3-8/+20
Existing header file design of having separate SoC specific header files for the common lpass driver has mutiple issues. This design is prone to break as an when new SoC header is added as the common DAI ids of other SoCs will be overwritten by the new ones. One of them surfaced by recent patch that adds support to sc7180, this one totally broke LPASS drivers on other Qualcomm SoCs. Before this gets worst, fix this by having a common header qcom,lpass.h. This should fix the issue and any new DAI ids should be added to the common header. This will be more sustainable then the existing design! Fixes: 12fbfc4cabec6595 ("ASoC: Add sc7180-lpass binding header hdmi define") Reported-by: Jun Nie <[email protected]> Reported-by: Stephan Gerhold <[email protected]> Tested-by: Srinivasa Rao <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-01-20Merge branch 'md-fixes' of ↵Jens Axboe1-0/+2
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.11 Pull MD fix from Song. * 'md-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: md: Set prev_flush_start and flush_bio in an atomic way
2021-01-20bpf: Fix signed_{sub,add32}_overflows type handlingDaniel Borkmann1-3/+3
Fix incorrect signed_{sub,add32}_overflows() input types (and a related buggy comment). It looks like this might have slipped in via copy/paste issue, also given prior to 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") the signature of signed_sub_overflows() had s64 a and s64 b as its input args whereas now they are truncated to s32. Thus restore proper types. Also, the case of signed_add32_overflows() is not consistent to signed_sub32_overflows(). Both have s32 as inputs, therefore align the former. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Reported-by: De4dCr0w <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]>
2021-01-20md: Set prev_flush_start and flush_bio in an atomic wayXiao Ni1-0/+2
One customer reports a crash problem which causes by flush request. It triggers a warning before crash. /* new request after previous flush is completed */ if (ktime_after(req_start, mddev->prev_flush_start)) { WARN_ON(mddev->flush_bio); mddev->flush_bio = bio; bio = NULL; } The WARN_ON is triggered. We use spin lock to protect prev_flush_start and flush_bio in md_flush_request. But there is no lock protection in md_submit_flush_data. It can set flush_bio to NULL first because of compiler reordering write instructions. For example, flush bio1 sets flush bio to NULL first in md_submit_flush_data. An interrupt or vmware causing an extended stall happen between updating flush_bio and prev_flush_start. Because flush_bio is NULL, flush bio2 can get the lock and submit to underlayer disks. Then flush bio1 updates prev_flush_start after the interrupt or extended stall. Then flush bio3 enters in md_flush_request. The start time req_start is behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK again. INIT_WORK() will re-initialize the list pointers in the work_struct, which then can result in a corrupted work list and the work_struct queued a second time. With the work list corrupted, it can lead in invalid work items being used and cause a crash in process_one_work. We need to make sure only one flush bio can be handled at one same time. So add spin lock in md_submit_flush_data to protect prev_flush_start and flush_bio in an atomic way. Reviewed-by: David Jeffery <[email protected]> Signed-off-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]>
2021-01-20can: peak_usb: fix use after free bugsVincent Mailhol1-4/+4
After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue. Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-20can: vxcan: vxcan_xmit: fix use after free bugVincent Mailhol1-2/+4
After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the canfd_frame cfd which aliases skb memory is accessed after the netif_rx_ni(). Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-20can: dev: can_restart: fix use after free bugVincent Mailhol1-2/+2
After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len; Reordering the lines solves the issue. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-20drm/syncobj: Fix use-after-freeDaniel Vetter1-3/+5
While reviewing Christian's annotation patch I noticed that we have a user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj reference before we've completed the waiting. Of course usually there's nothing bad happening here since userspace keeps the reference, but we can't rely on userspace to play nice here! Signed-off-by: Daniel Vetter <[email protected]> Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in drm_syncobj_find_fence v4") Reviewed-by: Christian König <[email protected]> Cc: Christian König <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.2+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-01-20powerpc/64s: fix scv entry fallback flush vs interruptNicholas Piggin6-4/+71
The L1D flush fallback functions are not recoverable vs interrupts, yet the scv entry flush runs with MSR[EE]=1. This can result in a timer (soft-NMI) or MCE or SRESET interrupt hitting here and overwriting the EXRFI save area, which ends up corrupting userspace registers for scv return. Fix this by disabling RI and EE for the scv entry fallback flush. Fixes: f79643787e0a0 ("powerpc/64s: flush L1D on kernel entry") Cc: [email protected] # 5.9+ which also have flush L1D patch backport Reported-by: Tulio Magno Quites Machado Filho <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-19tcp: fix TCP socket rehash stats mis-accountingYuchung Cheng3-22/+22
The previous commit 32efcc06d2a1 ("tcp: export count for rehash attempts") would mis-account rehashing SNMP and socket stats: a. During handshake of an active open, only counts the first SYN timeout b. After handshake of passive and active open, stop updating after (roughly) TCP_RETRIES1 recurring RTOs c. After the socket aborts, over count timeout_rehash by 1 This patch fixes this by checking the rehash result from sk_rethink_txhash. Fixes: 32efcc06d2a1 ("tcp: export count for rehash attempts") Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19net: dsa: b53: fix an off by one in checking "vlan->vid"Dan Carpenter1-1/+1
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: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19tcp: do not mess with cloned skbs in tcp_add_backlog()Eric Dumazet1-12/+13
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: 4f693b55c3d2 ("tcp: implement coalescing on backlog queue") Signed-off-by: Eric Dumazet <[email protected]> Bisected-by: Juerg Haefliger <[email protected]> Tested-by: Juerg Haefliger <[email protected]> Reported-by: Heiner Kallweit <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209423 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19selftests: net: fib_tests: remove duplicate log testHangbin Liu1-1/+0
The previous test added an address with a specified metric and check if correspond route was created. I somehow added two logs for the same test. Remove the duplicated one. Reported-by: Antoine Tenart <[email protected]> Fixes: 0d29169a708b ("selftests/net/fib_tests: update addr_metric_test for peer route testing") Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-20selftests/powerpc: Only test lwm/stmw on big endianMichael Ellerman1-1/+4
Newer binutils (>= 2.36) refuse to assemble lmw/stmw when building in little endian mode. That breaks compilation of our alignment handler test: /tmp/cco4l14N.s: Assembler messages: /tmp/cco4l14N.s:1440: Error: `lmw' invalid when little-endian /tmp/cco4l14N.s:1814: Error: `stmw' invalid when little-endian make[2]: *** [../../lib.mk:139: /output/kselftest/powerpc/alignment/alignment_handler] Error 1 These tests do pass on little endian machines, as the kernel will still emulate those instructions even when running little endian (which is arguably a kernel bug). But we don't really need to test that case, so ifdef those instructions out to get the alignment test building again. Reported-by: Libor Pechacek <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Tested-by: Libor Pechacek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-19net: nfc: nci: fix the wrong NCI_CORE_INIT parametersBongsu Jeon1-1/+1
Fix the code because NCI_CORE_INIT_CMD includes two parameters in NCI2.0 but there is no parameters in NCI1.x. Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence") Signed-off-by: Bongsu Jeon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19sh_eth: Fix power down vs. is_opened flag orderingGeert Uytterhoeven1-2/+2
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: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Sergei Shtylyov <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabledTariq Toukan2-0/+8
With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be logically done when RXCSUM offload is off. Fixes: 14136564c8ee ("net: Add TLS RX offload feature") Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Boris Pismenny <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19Merge branch 'ipv4-ensure-ecn-bits-don-t-influence-source-address-validation'Jakub Kicinski2-2/+3
Guillaume Nault says: ==================== ipv4: Ensure ECN bits don't influence source address validation Functions that end up calling fib_table_lookup() should clear the ECN bits from the TOS, otherwise ECT(0) and ECT(1) packets can be treated differently. Most functions already clear the ECN bits, but there are a few cases where this is not done. This series only fixes the ones related to source address validation. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19netfilter: rpfilter: mask ecn bits before fib lookupGuillaume Nault1-1/+1
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 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 0% packet loss ... Now use iptable's rpfilter module in ns1: $ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert -j DROP Not-ECT and ECT(1) packets still pass: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... But ECT(0) and ECN packets are dropped: $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 100% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 100% packet loss ... After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore. Fixes: 8f97339d3feb ("netfilter: add ipv4 reverse path filter match") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19udp: mask TOS bits in udp_v4_early_demux()Guillaume Nault1-1/+2
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: bc044e8db796 ("udp: perform source validation for mcast early demux") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19xsk: Clear pool even for inactive queuesMaxim Mikityanskiy1-2/+2
The number of queues can change by other means, rather than ethtool. For example, attaching an mqprio qdisc with num_tc > 1 leads to creating multiple sets of TX queues, which may be then destroyed when mqprio is deleted. If an AF_XDP socket is created while mqprio is active, dev->_tx[queue_id].pool will be filled, but then real_num_tx_queues may decrease with deletion of mqprio, which will mean that the pool won't be NULLed, and a further increase of the number of TX queues may expose a dangling pointer. To avoid any potential misbehavior, this commit clears pool for RX and TX queues, regardless of real_num_*_queues, still taking into consideration num_*_queues to avoid overflows. Fixes: 1c1efc2af158 ("xsk: Create and free buffer pool independently from umem") Fixes: a41b4f3c58dd ("xsk: simplify xdp_clear_umem_at_qid implementation") Signed-off-by: Maxim Mikityanskiy <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Björn Töpel <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-01-19Merge tag 'task_work-2021-01-19' of git://git.kernel.dk/linux-blockLinus Torvalds1-0/+3
Pull task_work fix from Jens Axboe: "The TIF_NOTIFY_SIGNAL change inadvertently removed the unconditional task_work run we had in get_signal(). This caused a regression for some setups, since we're relying on eg ____fput() being run to close and release, for example, a pipe and wake the other end. For 5.11, I prefer the simple solution of just reinstating the unconditional run, even if it conceptually doesn't make much sense - if you need that kind of guarantee, you should be using TWA_SIGNAL instead of TWA_NOTIFY. But it's the trivial fix for 5.11, and would ensure that other potential gotchas/assumptions for task_work don't regress for 5.11. We're looking into further simplifying the task_work notifications for 5.12 which would resolve that too" * tag 'task_work-2021-01-19' of git://git.kernel.dk/linux-block: task_work: unconditionally run task_work from get_signal()
2021-01-20openrisc: io: Add missing __iomem annotation to iounmap()Geert Uytterhoeven2-2/+2
With C=1: drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem *[assigned] base @@ drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: expected void *addr drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: got void [noderef] __iomem *[assigned] base Fix this by adding the missing __iomem annotation to iounmap(). Reported-by: kernel test robot <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Stafford Horne <[email protected]>
2021-01-19bpf: Fix helper bpf_map_peek_elem_proto pointing to wrong callbackMircea Cirjaliu1-1/+1
I assume this was obtained by copy/paste. Point it to bpf_map_peek_elem() instead of bpf_map_pop_elem(). In practice it may have been less likely hit when under JIT given shielded via 84430d4232c3 ("bpf, verifier: avoid retpoline for map push/pop/peek operation"). Fixes: f1a2e44a3aec ("bpf: add queue and stack maps") Signed-off-by: Mircea Cirjaliu <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Cc: Mauricio Vasquez <[email protected]> Link: https://lore.kernel.org/bpf/AM7PR02MB6082663DFDCCE8DA7A6DD6B1BBA30@AM7PR02MB6082.eurprd02.prod.outlook.com
2021-01-19Merge tag 'nfsd-5.11-2' of ↵Linus Torvalds3-9/+61
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fixes from Chuck Lever: - Avoid exposing parent of root directory in NFSv3 READDIRPLUS results - Fix a tracepoint change that went in the initial 5.11 merge * tag 'nfsd-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: SUNRPC: Move the svc_xdr_recvfrom tracepoint again nfsd4: readdirplus shouldn't return parent of export
2021-01-19Merge tag 'hyperv-fixes-signed-20210119' of ↵Linus Torvalds1-3/+26
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fix from Wei Liu: "One patch from Dexuan to fix clockevent initialization" * tag 'hyperv-fixes-signed-20210119' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: x86/hyperv: Initialize clockevents after LAPIC is initialized
2021-01-19Merge branch 'sh_eth-fix-reboot-crash'Jakub Kicinski3-2/+33
Geert Uytterhoeven says: ==================== sh_eth: Fix reboot crash This patch fixes a regression v5.11-rc1, where rebooting while a sh_eth device is not opened will cause a crash. Changes compared to v1: - Export mdiobb_{read,write}(), - Call mdiobb_{read,write}() now they are exported, - Use mii_bus.parent to avoid bb_info.dev copy, - Drop RFC state. Alternatively, mdio-bitbang could provide Runtime PM-aware wrappers itself, and use them either manually (through a new parameter to alloc_mdio_bitbang(), or a new alloc_mdio_bitbang_*() function), or automatically (e.g. if pm_runtime_enabled() returns true). Note that the latter requires a "struct device *" parameter to operate on. Currently there are only two drivers that call alloc_mdio_bitbang() and use Runtime PM: the Renesas sh_eth and ravb drivers. This series fixes the former, while the latter is not affected (it keeps the device powered all the time between driver probe and driver unbind, and changing that seems to be non-trivial). ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19sh_eth: Make PHY access aware of Runtime PM to fix reboot crashGeert Uytterhoeven1-0/+26
Wolfram reports that his R-Car H2-based Lager board can no longer be rebooted in v5.11-rc1, as it crashes with an imprecise external abort. The issue can be reproduced on other boards (e.g. Koelsch with R-Car M2-W) too, if CONFIG_IP_PNP is disabled, and the Ethernet interface is down at reboot time: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 pgd = (ptrval) [00000000] *pgd=422b6835, *pte=00000000, *ppte=00000000 Internal error: : 1406 [#1] ARM Modules linked in: CPU: 0 PID: 1105 Comm: init Tainted: G W 5.10.0-rc1-00402-ge2f016cf7751 #1048 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) PC is at sh_mdio_ctrl+0x44/0x60 LR is at sh_mmd_ctrl+0x20/0x24 ... Backtrace: [<c0451f30>] (sh_mdio_ctrl) from [<c0451fd4>] (sh_mmd_ctrl+0x20/0x24) r7:0000001f r6:00000020 r5:00000002 r4:c22a1dc4 [<c0451fb4>] (sh_mmd_ctrl) from [<c044fc18>] (mdiobb_cmd+0x38/0xa8) [<c044fbe0>] (mdiobb_cmd) from [<c044feb8>] (mdiobb_read+0x58/0xdc) r9:c229f844 r8:c0c329dc r7:c221e000 r6:00000001 r5:c22a1dc4 r4:00000001 [<c044fe60>] (mdiobb_read) from [<c044c854>] (__mdiobus_read+0x74/0xe0) r7:0000001f r6:00000001 r5:c221e000 r4:c221e000 [<c044c7e0>] (__mdiobus_read) from [<c044c9d8>] (mdiobus_read+0x40/0x54) r7:0000001f r6:00000001 r5:c221e000 r4:c221e458 [<c044c998>] (mdiobus_read) from [<c044d678>] (phy_read+0x1c/0x20) r7:ffffe000 r6:c221e470 r5:00000200 r4:c229f800 [<c044d65c>] (phy_read) from [<c044d94c>] (kszphy_config_intr+0x44/0x80) [<c044d908>] (kszphy_config_intr) from [<c044694c>] (phy_disable_interrupts+0x44/0x50) r5:c229f800 r4:c229f800 [<c0446908>] (phy_disable_interrupts) from [<c0449370>] (phy_shutdown+0x18/0x1c) r5:c229f800 r4:c229f804 [<c0449358>] (phy_shutdown) from [<c040066c>] (device_shutdown+0x168/0x1f8) [<c0400504>] (device_shutdown) from [<c013de44>] (kernel_restart_prepare+0x3c/0x48) r9:c22d2000 r8:c0100264 r7:c0b0d034 r6:00000000 r5:4321fedc r4:00000000 [<c013de08>] (kernel_restart_prepare) from [<c013dee0>] (kernel_restart+0x1c/0x60) [<c013dec4>] (kernel_restart) from [<c013e1d8>] (__do_sys_reboot+0x168/0x208) r5:4321fedc r4:01234567 [<c013e070>] (__do_sys_reboot) from [<c013e2e8>] (sys_reboot+0x18/0x1c) r7:00000058 r6:00000000 r5:00000000 r4:00000000 [<c013e2d0>] (sys_reboot) from [<c0100060>] (ret_fast_syscall+0x0/0x54) As of commit e2f016cf775129c0 ("net: phy: add a shutdown procedure"), system reboot calls phy_disable_interrupts() during shutdown. As this happens unconditionally, the PHY registers may be accessed while the device is suspended, causing undefined behavior, which may crash the system. Fix this by wrapping the PHY bitbang accessors in the sh_eth driver by wrappers that take care of Runtime PM, to resume the device when needed. Reported-by: Wolfram Sang <[email protected]> Suggested-by: Andrew Lunn <[email protected]> Signed-off-by: Geert Uytterhoeven <[email protected]> Tested-by: Wolfram Sang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19mdio-bitbang: Export mdiobb_{read,write}()Geert Uytterhoeven2-2/+7
Export mdiobb_read() and mdiobb_write(), so Ethernet controller drivers can call them from their MDIO read/write wrappers. Signed-off-by: Geert Uytterhoeven <[email protected]> Tested-by: Wolfram Sang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19net: core: devlink: use right genl user_ptr when handling port param get/setOleksandr Mazur1-2/+2
Fix incorrect user_ptr dereferencing when handling port param get/set: idx [0] stores the 'struct devlink' pointer; idx [1] stores the 'struct devlink_port' pointer; Fixes: 637989b5d77e ("devlink: Always use user_ptr[0] for devlink and simplify post_doit") CC: Parav Pandit <[email protected]> Signed-off-by: Oleksandr Mazur <[email protected]> Signed-off-by: Vadym Kochan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-19x86: PM: Register syscore_ops for scale invarianceRafael J. Wysocki1-0/+19
On x86 scale invariace tends to be disabled during resume from suspend-to-RAM, because the MPERF or APERF MSR values are not as expected then due to updates taking place after the platform firmware has been invoked to complete the suspend transition. That, of course, is not desirable, especially if the schedutil scaling governor is in use, because the lack of scale invariance causes it to be less reliable. To counter that effect, modify init_freq_invariance() to register a syscore_ops object for scale invariance with the ->resume callback pointing to init_counter_refs() which will run on the CPU starting the resume transition (the other CPUs will be taken care of the "online" operations taking place later). Fixes: e2b0d619b400 ("x86, sched: check for counters overflow in frequency invariant accounting") Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Giovanni Gherdovich <[email protected]> Link: https://lkml.kernel.org/r/1803209.Mvru99baaF@kreacher
2021-01-19ALSA: hda: Balance runtime/system PM if direct-complete is disabledKai-Heng Feng1-17/+7
After hibernation, HDA controller can't be runtime-suspended after commit 215a22ed31a1 ("ALSA: hda: Refactor codjc PM to use direct-complete optimization"), which enables direct-complete for HDA codec. The HDA codec driver didn't expect direct-complete will be disabled after it returns a positive value from prepare() callback. However, there are some places that PM core can disable direct-complete. For instance, system hibernation or when codec has subordinates like LEDs. So if the codec is prepared for direct-complete but PM core still calls codec's suspend or freeze callback, partially revert the commit and take the original approach, which uses pm_runtime_force_*() helpers to ensure PM refcount are balanced. Meanwhile, still keep prepare() and complete() callbacks to enable direct-complete and request a resume for jack detection, respectively. Reported-by: Kenneth R. Crudup <[email protected]> Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Signed-off-by: Kai-Heng Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-01-19drm/vram-helper: Reuse existing page mappings in vmapThomas Zimmermann1-3/+11
For performance, BO page mappings can stay in place even if the map counter has returned to 0. In these cases, the existing page mapping has to be reused by the next vmap operation. Otherwise a new mapping would be installed and the old mapping's pages leak. Fix the issue by reusing existing page mappings for vmap operations. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 1086db71a1db ("drm/vram-helper: Remove invariant parameters from internal kmap function") Acked-by: Christian König <[email protected]> Tested-by: Eli Cohen <[email protected]> Reported-by: Eli Cohen <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Christian König <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-01-19drm/atomic: put state on error pathPan Bian1-1/+1
Put the state before returning error code. Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.") Signed-off-by: Pan Bian <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-01-19usb: bdc: Make bdc pci driver depend on BROKENPatrik Jakobsson1-1/+1
The bdc pci driver is going to be removed due to it not existing in the wild. This patch turns off compilation of the driver so that stable kernels can also pick up the change. This helps the out-of-tree facetimehd webcam driver as the pci id conflicts with bdc. Cc: Al Cooper <[email protected]> Cc: <[email protected]> Acked-by: Felipe Balbi <[email protected]> Signed-off-by: Patrik Jakobsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-01-19gpio: tegra: Add missing dependenciesThierry Reding1-0/+2
Commit efcdca286eef ("gpio: tegra: Convert to gpio_irq_chip") moved the Tegra GPIO driver to the generic GPIO IRQ chip infrastructure and made the IRQ domain hierarchical, so the driver needs to pull in the support infrastructure via the GPIOLIB_IRQCHIP and IRQ_DOMAIN_HIERARCHY Kconfig options. Fixes: efcdca286eef ("gpio: tegra: Convert to gpio_irq_chip") Reported-by: kernel test robot <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-01-19gpio: sifive: select IRQ_DOMAIN_HIERARCHY rather than depend on itRandy Dunlap1-1/+2
This is the only driver in the kernel source tree that depends on IRQ_DOMAIN_HIERARCHY instead of selecting it. Since it is not a visible Kconfig symbol, depending on it (expecting a user to set/enable it) doesn't make much sense, so change it to select instead of "depends on". Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Signed-off-by: Randy Dunlap <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Bartosz Golaszewski <[email protected]> Cc: [email protected] Cc: Thierry Reding <[email protected]> Cc: Greentime Hu <[email protected]> Cc: Yash Shah <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-01-19gpio: mvebu: fix pwm .get_state period calculationBaruch Siach1-11/+8
The period is the sum of on and off values. That is, calculate period as ($on + $off) / clkrate instead of $off / clkrate - $on / clkrate that makes no sense. Reported-by: Russell King <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Fixes: 757642f9a584e ("gpio: mvebu: Add limited PWM support") Signed-off-by: Baruch Siach <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-01-19gpiolib: add a warning on gpiochip->to_irq definedNikita Shubin1-0/+3
gpiochip->to_irq method is redefined in gpiochip_add_irqchip. A lot of gpiod driver's still define ->to_irq method, let's give a gentle warning that they can no longer rely on it, so they can remove it on ocassion. Fixes: e0d8972898139 ("gpio: Implement tighter IRQ chip integration") Signed-off-by: Nikita Shubin <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-01-19printk: fix buffer overflow potential for print_text()John Ogness1-9/+27
Before the commit 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer"), msg_print_text() would only write up to size-1 bytes into the provided buffer. Some callers expect this behavior and append a terminator to returned string. In particular: arch/powerpc/xmon/xmon.c:dump_log_buf() arch/um/kernel/kmsg_dump.c:kmsg_dumper_stdout() msg_print_text() has been replaced by record_print_text(), which currently fills the full size of the buffer. This causes a buffer overflow for the above callers. Change record_print_text() so that it will only use size-1 bytes for text data. Also, for paranoia sakes, add a terminator after the text data. And finally, document this behavior so that it is clear that only size-1 bytes are used and a terminator is added. Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer") Cc: [email protected] # 5.10+ Signed-off-by: John Ogness <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Acked-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-19drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4Ville Syrjälä3-6/+8
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're actually outputting YCbCr 4:4:4. It would appear some protocol converters blindy consult this bit even when the source is outputting RGB, resulting in a visual mess. Cc: [email protected] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Fixes: 181567aa9f0d ("drm/i915: Do YCbCr 444->420 conversion via DP protocol converters") Reviewed-by: Jani Nikula <[email protected]> (cherry picked from commit 3170a21f7059c4660c469f59bf529f372a57da5f) Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-01-18tcp: fix TCP_USER_TIMEOUT with zero windowEnke Chen6-7/+14
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 <[email protected]> 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: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT") Reported-by: William McCall <[email protected]> Co-developed-by: Neal Cardwell <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: Enke Chen <[email protected]> Reviewed-by: Yuchung Cheng <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-18Merge branch 'ipv6-fixes-for-the-multicast-routes'Jakub Kicinski1-1/+2
Matteo Croce says: ==================== ipv6: fixes for the multicast routes Fix two wrong flags in the IPv6 multicast routes created by the autoconf code. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-18ipv6: set multicast flag on the multicast routeMatteo Croce1-1/+1
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: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info") Signed-off-by: Matteo Croce <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.