aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-25wil6210: account for napi_gro_receive never returning GRO_DROPJason A. Donenfeld1-28/+11
The napi_gro_receive function no longer returns GRO_DROP ever, making handling GRO_DROP dead code. This commit removes that dead code. Further, it's not even clear that device drivers have any business in taking action after passing off received packets; that's arguably out of their hands. In this case, too, the non-gro path didn't bother checking the return value. Plus, this had some clunky debugging functions that duplicated code from elsewhere and was generally pretty messy. So, this commit cleans that all up too. Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25hns: do not cast return value of napi_gro_receive to nullJason A. Donenfeld1-1/+1
Basically no drivers care about the return value here, and there's no __must_check that would make casting to void sensible, so remove it. Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25socionext: account for napi_gro_receive never returning GRO_DROPJason A. Donenfeld1-2/+3
The napi_gro_receive function no longer returns GRO_DROP ever, making handling GRO_DROP dead code. This commit removes that dead code. Further, it's not even clear that device drivers have any business in taking action after passing off received packets; that's arguably out of their hands. Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25wireguard: receive: account for napi_gro_receive never returning GRO_DROPJason A. Donenfeld1-8/+2
The napi_gro_receive function no longer returns GRO_DROP ever, making handling GRO_DROP dead code. This commit removes that dead code. Further, it's not even clear that device drivers have any business in taking action after passing off received packets; that's arguably out of their hands. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25vxlan: fix last fdb index during dump of fdb with nhidRoopa Prabhu1-0/+4
This patch fixes last saved fdb index in fdb dump handler when handling fdb's with nhid. Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Signed-off-by: Roopa Prabhu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25sctp: Don't advertise IPv4 addresses if ipv6only is set on the socketMarcelo Ricardo Leitner4-5/+12
If a socket is set ipv6only, it will still send IPv4 addresses in the INIT and INIT_ACK packets. This potentially misleads the peer into using them, which then would cause association termination. The fix is to not add IPv4 addresses to ipv6only sockets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Corey Minyard <[email protected]> Signed-off-by: Marcelo Ricardo Leitner <[email protected]> Tested-by: Corey Minyard <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25tc-testing: avoid action cookies with odd length.Briana Oursler3-7/+7
Update odd length cookie hexstrings in csum.json, tunnel_key.json and bpf.json to be even length to comply with check enforced in commit 0149dabf2a1b ("tc: m_actions: check cookie hexstring len") in iproute2. Signed-off-by: Briana Oursler <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Reviewed-by: Davide Caratti <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25Merge branch 'tcp_cubic-fix-spurious-HYSTART_DELAY-on-RTT-decrease'David S. Miller2-6/+4
Neal Cardwell says: ==================== tcp_cubic: fix spurious HYSTART_DELAY on RTT decrease This series fixes a long-standing bug in the TCP CUBIC HYSTART_DELAY mechanim recently reported by Mirja Kuehlewind. The code can cause a spurious exit of slow start in some particular cases: upon an RTT decrease that happens on the 9th or later ACK in a round trip. This series fixes the original Hystart code and also the recent BPF implementation. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-06-25bpf: tcp: bpf_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTTNeal Cardwell1-3/+2
Apply the fix from: "tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT" to the BPF implementation of TCP CUBIC congestion control. Repeating the commit description here for completeness: Mirja Kuehlewind reported a bug in Linux TCP CUBIC Hystart, where Hystart HYSTART_DELAY mechanism can exit Slow Start spuriously on an ACK when the minimum rtt of a connection goes down. From inspection it is clear from the existing code that this could happen in an example like the following: o The first 8 RTT samples in a round trip are 150ms, resulting in a curr_rtt of 150ms and a delay_min of 150ms. o The 9th RTT sample is 100ms. The curr_rtt does not change after the first 8 samples, so curr_rtt remains 150ms. But delay_min can be lowered at any time, so delay_min falls to 100ms. The code executes the HYSTART_DELAY comparison between curr_rtt of 150ms and delay_min of 100ms, and the curr_rtt is declared far enough above delay_min to force a (spurious) exit of Slow start. The fix here is simple: allow every RTT sample in a round trip to lower the curr_rtt. Fixes: 6de4a9c430b5 ("bpf: tcp: Add bpf_cubic example") Reported-by: Mirja Kuehlewind <[email protected]> Signed-off-by: Neal Cardwell <[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-06-25tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTTNeal Cardwell1-3/+2
Mirja Kuehlewind reported a bug in Linux TCP CUBIC Hystart, where Hystart HYSTART_DELAY mechanism can exit Slow Start spuriously on an ACK when the minimum rtt of a connection goes down. From inspection it is clear from the existing code that this could happen in an example like the following: o The first 8 RTT samples in a round trip are 150ms, resulting in a curr_rtt of 150ms and a delay_min of 150ms. o The 9th RTT sample is 100ms. The curr_rtt does not change after the first 8 samples, so curr_rtt remains 150ms. But delay_min can be lowered at any time, so delay_min falls to 100ms. The code executes the HYSTART_DELAY comparison between curr_rtt of 150ms and delay_min of 100ms, and the curr_rtt is declared far enough above delay_min to force a (spurious) exit of Slow start. The fix here is simple: allow every RTT sample in a round trip to lower the curr_rtt. Fixes: ae27e98a5152 ("[TCP] CUBIC v2.3") Reported-by: Mirja Kuehlewind <[email protected]> Signed-off-by: Neal Cardwell <[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-06-25Merge branch 'Fixes-for-SJA1105-DSA-tc-gate-action'David S. Miller1-160/+167
Vladimir Oltean says: ==================== Fixes for SJA1105 DSA tc-gate action This small series fixes 2 bugs in the tc-gate implementation: 1. The TAS state machine keeps getting rescheduled even after removing tc-gate actions on all ports. 2. tc-gate actions with only one gate control list entry are installed to hardware with an incorrect interval of zero, which makes the switch erroneously drop those packets (since the configuration is invalid). To keep the code palatable, a forward-declaration was avoided by moving some code around in patch 1/4. I hope that isn't too much of an issue. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: dsa: sja1105: fix tc-gate schedule with single elementVladimir Oltean1-2/+1
The sja1105_gating_cfg_time_to_interval function does this, as per the comments: /* The gate entries contain absolute times in their e->interval field. Convert * that to proper intervals (i.e. "0, 5, 10, 15" to "5, 5, 5, 5"). */ To perform that task, it iterates over gating_cfg->entries, at each step updating the interval of the _previous_ entry. So one interval remains to be updated at the end of the loop: the last one (since it isn't "prev" for anyone else). But there was an erroneous check, that the last element's interval should not be updated if it's also the only element. I'm not quite sure why that check was there, but it's clearly incorrect, as a tc-gate schedule with a single element would get an e->interval of zero, regardless of the duration requested by the user. The switch wouldn't even consider this configuration as valid: it will just drop all traffic that matches the rule. Fixes: 834f8933d5dd ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links") Reported-by: Xiaoliang Yang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: dsa: sja1105: recalculate gating subschedule after deleting tc-gate rulesVladimir Oltean1-0/+8
Currently, tas_data->enabled would remain true even after deleting all tc-gate rules from the switch ports, which would cause the sja1105_tas_state_machine to get unnecessarily scheduled. Also, if there were any errors which would prevent the hardware from enabling the gating schedule, the sja1105_tas_state_machine would continuously detect and print that, spamming the kernel log, even if the rules were subsequently deleted. The rules themselves are _not_ active, because sja1105_init_scheduling does enough of a job to not install the gating schedule in the static config. But the virtual link rules themselves are still present. So call the functions that remove the tc-gate configuration from priv->tas_data.gating_cfg, so that tas_data->enabled can be set to false, and sja1105_tas_state_machine will stop from being scheduled. Fixes: 834f8933d5dd ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: dsa: sja1105: unconditionally free old gating configVladimir Oltean1-2/+2
Currently sja1105_compose_gating_subschedule is not prepared to be called for the case where we want to recompute the global tc-gate configuration after we've deleted those actions on a port. After deleting the tc-gate actions on the last port, max_cycle_time would become zero, and that would incorrectly prevent sja1105_free_gating_config from getting called. So move the freeing function above the check for the need to apply a new configuration. Fixes: 834f8933d5dd ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: dsa: sja1105: move sja1105_compose_gating_subschedule at the topVladimir Oltean1-160/+160
It turns out that sja1105_compose_gating_subschedule must also be called from sja1105_vl_delete, to recalculate the overall tc-gate configuration. Currently this is not possible without introducing a forward declaration. So move the function at the top of the file, along with its dependencies. Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()Misono Tomohiro1-1/+3
Although it rarely happens, we should call free_capabilities() if error happens after read_capabilities() to free allocated strings. Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters") Signed-off-by: Misono Tomohiro <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-06-26fork: annotate data race in copy_process()Weilong Chen1-1/+1
KCSAN reported data race reading and writing nr_threads and max_threads. The data race is intentional and benign. This is obvious from the comment above it and based on general consensus when discussing this issue. So there's no need for any heavy atomic or *_ONCE() machinery here. In accordance with the newly introduced data_race() annotation consensus, mark the offending line with data_race(). Here it's actually useful not just to silence KCSAN but to also clearly communicate that the race is intentional. This is especially helpful since nr_threads is otherwise protected by tasklist_lock. BUG: KCSAN: data-race in copy_process / copy_process write to 0xffffffff86205cf8 of 4 bytes by task 14779 on cpu 1: copy_process+0x2eba/0x3c40 kernel/fork.c:2273 _do_fork+0xfe/0x7a0 kernel/fork.c:2421 __do_sys_clone kernel/fork.c:2576 [inline] __se_sys_clone kernel/fork.c:2557 [inline] __x64_sys_clone+0x130/0x170 kernel/fork.c:2557 do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffffffff86205cf8 of 4 bytes by task 6944 on cpu 0: copy_process+0x94d/0x3c40 kernel/fork.c:1954 _do_fork+0xfe/0x7a0 kernel/fork.c:2421 __do_sys_clone kernel/fork.c:2576 [inline] __se_sys_clone kernel/fork.c:2557 [inline] __x64_sys_clone+0x130/0x170 kernel/fork.c:2557 do_syscall_64+0xcc/0x3a0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Link: https://groups.google.com/forum/#!msg/syzkaller-upstream-mo deration/thvp7AHs5Ew/aPdYLXfYBQAJ Reported-by: [email protected] Signed-off-by: Zefan Li <[email protected]> Signed-off-by: Weilong Chen <[email protected]> Acked-by: Christian Brauner <[email protected]> Cc: Qian Cai <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Marco Elver <[email protected]> [[email protected]: rewrite commit message] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-06-25net: macb: free resources on failure path of at91ether_open()Claudiu Beznea1-43/+73
DMA buffers were not freed on failure path of at91ether_open(). Along with changes for freeing the DMA buffers the enable/disable interrupt instructions were moved to at91ether_start()/at91ether_stop() functions and the operations on at91ether_stop() were done in their reverse order (compared with how is done in at91ether_start()): before this patch the operation order on interface open path was as follows: 1/ alloc DMA buffers 2/ enable tx, rx 3/ enable interrupts and the order on interface close path was as follows: 1/ disable tx, rx 2/ disable interrupts 3/ free dma buffers. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: macb: call pm_runtime_put_sync on failure pathClaudiu Beznea1-2/+6
Call pm_runtime_put_sync() on failure path of at91ether_open. Fixes: e6a41c23df0d ("net: macb: ensure interface is not suspended on at91rm9200") Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25riscv: Fixup __vdso_gettimeofday broke dynamic ftraceGuo Ren1-0/+3
For linux-5.8-rc1, enable ftrace of riscv will cause boot panic: [ 2.388980] Run /sbin/init as init process [ 2.529938] init[39]: unhandled signal 4 code 0x1 at 0x0000003ff449e000 [ 2.531078] CPU: 0 PID: 39 Comm: init Not tainted 5.8.0-rc1-dirty #13 [ 2.532719] epc: 0000003ff449e000 ra : 0000003ff449e954 sp : 0000003fffedb900 [ 2.534005] gp : 00000000000e8528 tp : 0000003ff449d800 t0 : 000000000000001e [ 2.534965] t1 : 000000000000000a t2 : 0000003fffedb89e s0 : 0000003fffedb920 [ 2.536279] s1 : 0000003fffedb940 a0 : 0000003ff43d4b2c a1 : 0000000000000000 [ 2.537334] a2 : 0000000000000001 a3 : 0000000000000000 a4 : fffffffffbad8000 [ 2.538466] a5 : 0000003ff449e93a a6 : 0000000000000000 a7 : 0000000000000000 [ 2.539511] s2 : 0000000000000000 s3 : 0000003ff448412c s4 : 0000000000000010 [ 2.541260] s5 : 0000000000000016 s6 : 00000000000d0a30 s7 : 0000003fffedba70 [ 2.542152] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000003fffedb960 [ 2.543335] s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000003fffedb8a0 [ 2.544471] t5 : 0000000000000000 t6 : 0000000000000000 [ 2.545730] status: 0000000000004020 badaddr: 00000000464c457f cause: 0000000000000002 [ 2.549867] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 [ 2.551267] CPU: 0 PID: 1 Comm: init Not tainted 5.8.0-rc1-dirty #13 [ 2.552061] Call Trace: [ 2.552626] [<ffffffe00020374a>] walk_stackframe+0x0/0xc4 [ 2.553486] [<ffffffe0002039f4>] show_stack+0x40/0x4c [ 2.553995] [<ffffffe00054a6ae>] dump_stack+0x7a/0x98 [ 2.554615] [<ffffffe00020b9b8>] panic+0x114/0x2f4 [ 2.555395] [<ffffffe00020ebd6>] do_exit+0x89c/0x8c2 [ 2.555949] [<ffffffe00020f930>] do_group_exit+0x3a/0x90 [ 2.556715] [<ffffffe000219e08>] get_signal+0xe2/0x6e6 [ 2.557388] [<ffffffe000202d72>] do_notify_resume+0x6a/0x37a [ 2.558089] [<ffffffe000201c16>] ret_from_exception+0x0/0xc "ra:0x3ff449e954" is the return address of "call _mcount" in the prologue of __vdso_gettimeofday(). Without proper relocate, pc jmp to 0x0000003ff449e000 (vdso map base) with a illegal instruction trap. The solution comes from arch/arm64/kernel/vdso/Makefile: CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) - CC_FLAGS_SCS is ShadowCallStack feature in Clang and only implemented for arm64, no use for riscv. Fixes: ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the time-related functions") Cc: [email protected] Signed-off-by: Guo Ren <[email protected]> Reviewed-by: Vincent Chen <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-06-26i2c: fsi: Fix the port number field in status registerEddie James1-1/+1
The port number field in the status register was not correct, so fix it. Fixes: d6ffb6300116 ("i2c: Add FSI-attached I2C master algorithm") Signed-off-by: Eddie James <[email protected]> Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-06-25riscv: Add extern declarations for vDSO time-related functionsVincent Chen1-0/+6
Add extern declarations for vDSO time-related functions to notify the compiler these functions will be used in somewhere to avoid "no previous prototype" compile warning. Reported-by: kernel test robot <[email protected]> Signed-off-by: Vincent Chen <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-06-25clk: sifive: allocate sufficient memory for struct __prci_dataVincent Chen1-1/+4
The (struct __prci_data).hw_clks.hws is an array with dynamic elements. Using struct_size(pd, hw_clks.hws, ARRAY_SIZE(__prci_init_clocks)) instead of sizeof(*pd) to get the correct memory size of struct __prci_data for sifive/fu540-prci. After applying this modifications, the kernel runs smoothly with CONFIG_SLAB_FREELIST_RANDOM enabled on the HiFive unleashed board. Fixes: 30b8e27e3b58 ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block") Signed-off-by: Vincent Chen <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-06-25riscv: Add -fPIC option to CFLAGS_vgettimeofday.oVincent Chen1-1/+1
The time related vDSO functions use a variable, vdso_data, to access the vDSO data page to get the system time information. Because the vdso_data for CFLAGS_vgettimeofday.o is an external variable defined in vdso.o, the CFLAGS_vgettimeofday.o should be compiled with -fPIC to ensure that vdso_data is addressable. Reported-by: kernel test robot <[email protected]> Signed-off-by: Vincent Chen <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-06-25Merge tag 'fsnotify_for_v5.8-rc3' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull fsnotify fixlet from Jan Kara: "A performance improvement to reduce impact of fsnotify for inodes where it isn't used" * tag 'fsnotify_for_v5.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: fs: Do not check if there is a fsnotify watcher on pseudo inodes
2020-06-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller58-16/+344
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net, they are: 1) Unaligned atomic access in ipset, from Russell King. 2) Missing module description, from Rob Gill. 3) Patches to fix a module unload causing NULL pointer dereference in xtables, from David Wilder. For the record, I posting here his cover letter explaining the problem: A crash happened on ppc64le when running ltp network tests triggered by "rmmod iptable_mangle". See previous discussion in this thread: https://lists.openwall.net/netdev/2020/06/03/161 . In the crash I found in iptable_mangle_hook() that state->net->ipv4.iptable_mangle=NULL causing a NULL pointer dereference. net->ipv4.iptable_mangle is set to NULL in +iptable_mangle_net_exit() and called when ip_mangle modules is unloaded. A rmmod task was found running in the crash dump. A 2nd crash showed the same problem when running "rmmod iptable_filter" (net->ipv4.iptable_filter=NULL). To fix this I added .pre_exit hook in all iptable_foo.c. The pre_exit will un-register the underlying hook and exit would do the table freeing. The netns core does an unconditional +synchronize_rcu after the pre_exit hooks insuring no packets are in flight that have picked up the pointer before completing the un-register. These patches include changes for both iptables and ip6tables. We tested this fix with ltp running iptables01.sh and iptables01.sh -6 a loop for 72 hours. 4) Add a selftest for conntrack helper assignment, from Florian Westphal. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-06-25net: bridge: enfore alignment for ethernet addressThomas Martitz1-1/+1
The eth_addr member is passed to ether_addr functions that require 2-byte alignment, therefore the member must be properly aligned to avoid unaligned accesses. The problem is in place since the initial merge of multicast to unicast: commit 6db6f0eae6052b70885562e1733896647ec1d807 bridge: multicast to unicast Fixes: 6db6f0eae605 ("bridge: multicast to unicast") Cc: Roopa Prabhu <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Cc: David S. Miller <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Felix Fietkau <[email protected]> Signed-off-by: Thomas Martitz <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds22-124/+197
Pull rdma fixes from Jason Gunthorpe: "Several regression fixes from work that landed in the merge window, particularly in the mlx5 driver: - Various static checker and warning fixes - General bug fixes in rvt, qedr, hns, mlx5 and hfi1 - Several regression fixes related to the ECE and QP changes in last cycle - Fixes for a few long standing crashers in CMA, uverbs ioctl, and xrc" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (25 commits) IB/hfi1: Add atomic triggered sleep/wakeup IB/hfi1: Correct -EBUSY handling in tx code IB/hfi1: Fix module use count flaw due to leftover module put calls IB/hfi1: Restore kfree in dummy_netdev cleanup IB/mad: Fix use after free when destroying MAD agent RDMA/mlx5: Protect from kernel crash if XRC_TGT doesn't have udata RDMA/counter: Query a counter before release RDMA/mad: Fix possible memory leak in ib_mad_post_receive_mads() RDMA/mlx5: Fix integrity enabled QP creation RDMA/mlx5: Remove ECE limitation from the RAW_PACKET QPs RDMA/mlx5: Fix remote gid value in query QP RDMA/mlx5: Don't access ib_qp fields in internal destroy QP path RDMA/core: Check that type_attrs is not NULL prior access RDMA/hns: Fix an cmd queue issue when resetting RDMA/hns: Fix a calltrace when registering MR from userspace RDMA/mlx5: Add missed RST2INIT and INIT2INIT steps during ECE handshake RDMA/cma: Protect bind_list and listen_list while finding matching cm id RDMA/qedr: Fix KASAN: use-after-free in ucma_event_handler+0x532 RDMA/efa: Set maximum pkeys device attribute RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq ...
2020-06-25tcp: don't ignore ECN CWR on pure ACKDenis Kirjanov1-3/+11
there is a problem with the CWR flag set in an incoming ACK segment and it leads to the situation when the ECE flag is latched forever the following packetdrill script shows what happens: // Stack receives incoming segments with CE set +0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535 +0.0 <[ce] . 12001:13001(1000) ack 1001 win 65535 +0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535 // Stack repsonds with ECN ECHO +0.0 >[noecn] . 1001:1001(0) ack 12001 +0.0 >[noecn] E. 1001:1001(0) ack 13001 +0.0 >[noecn] E. 1001:1001(0) ack 14001 // Write a packet +0.1 write(3, ..., 1000) = 1000 +0.0 >[ect0] PE. 1001:2001(1000) ack 14001 // Pure ACK received +0.01 <[noecn] W. 14001:14001(0) ack 2001 win 65535 // Since CWR was sent, this packet should NOT have ECE set +0.1 write(3, ..., 1000) = 1000 +0.0 >[ect0] P. 2001:3001(1000) ack 14001 // but Linux will still keep ECE latched here, with packetdrill // flagging a missing ECE flag, expecting // >[ect0] PE. 2001:3001(1000) ack 14001 // in the script In the situation above we will continue to send ECN ECHO packets and trigger the peer to reduce the congestion window. To avoid that we can check CWR on pure ACKs received. v3: - Add a sequence check to avoid sending an ACK to an ACK v2: - Adjusted the comment - move CWR check before checking for unacknowledged packets Signed-off-by: Denis Kirjanov <[email protected]> Acked-by: Neal Cardwell <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25arm64: Add KRYO{3,4}XX silver CPU cores to SSB safelistSai Prakash Ranjan1-0/+2
QCOM KRYO{3,4}XX silver/LITTLE CPU cores are based on Cortex-A55 and are SSB safe, hence add them to SSB safelist -> arm64_ssb_cpus[]. Reported-by: Stephen Boyd <[email protected]> Signed-off-by: Sai Prakash Ranjan <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-06-25net: phy: mscc: avoid skcipher API for single block AES encryptionArd Biesheuvel2-33/+10
The skcipher API dynamically instantiates the transformation object on request that implements the requested algorithm optimally on the given platform. This notion of optimality only matters for cases like bulk network or disk encryption, where performance can be a bottleneck, or in cases where the algorithm itself is not known at compile time. In the mscc case, we are dealing with AES encryption of a single block, and so neither concern applies, and we are better off using the AES library interface, which is lightweight and safe for this kind of use. Note that the scatterlist API does not permit references to buffers that are located on the stack, so the existing code is incorrect in any case, but avoiding the skcipher and scatterlist APIs entirely is the most straight-forward approach to fixing this. Cc: Antoine Tenart <[email protected]> Cc: Andrew Lunn <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Heiner Kallweit <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Jakub Kicinski <[email protected]> Fixes: 28c5107aa904e ("net: phy: mscc: macsec support") Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Tested-by: Antoine Tenart <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-25Merge branch 'nvme-5.8' of git://git.infradead.org/nvme into block-5.8Jens Axboe7-25/+41
Pull NVMe fixes from Christoph. * 'nvme-5.8' of git://git.infradead.org/nvme: nvme-multipath: fix bogus request queue reference put nvme-multipath: fix deadlock due to head->lock nvme: don't protect ns mutation with ns->head->lock nvme-multipath: fix deadlock between ana_work and scan_work nvme: fix possible deadlock when I/O is blocked nvme-rdma: assign completion vector correctly nvme-loop: initialize tagset numa value to the value of the ctrl nvme-tcp: initialize tagset numa value to the value of the ctrl nvme-pci: initialize tagset numa value to the value of the ctrl nvme-pci: override the value of the controller's numa node nvme: set initial value for controller's numa node
2020-06-25drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RASIvan Mironov1-4/+7
I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and following started to happen on each boot: ... BUG: kernel NULL pointer dereference, address: 0000000000000128 ... CPU: 9 PID: 1940 Comm: modprobe Tainted: G E 5.7.2-200.im0.fc32.x86_64 #1 Hardware name: System manufacturer System Product Name/PRIME X570-P, BIOS 1407 04/02/2020 RIP: 0010:lock_bus+0x42/0x60 [amdgpu] ... Call Trace: i2c_smbus_xfer+0x3d/0xf0 i2c_default_probe+0xf3/0x130 i2c_detect.isra.0+0xfe/0x2b0 ? kfree+0xa3/0x200 ? kobject_uevent_env+0x11f/0x6a0 ? i2c_detect.isra.0+0x2b0/0x2b0 __process_new_driver+0x1b/0x20 bus_for_each_dev+0x64/0x90 ? 0xffffffffc0f34000 i2c_register_driver+0x73/0xc0 do_one_initcall+0x46/0x200 ? _cond_resched+0x16/0x40 ? kmem_cache_alloc_trace+0x167/0x220 ? do_init_module+0x23/0x260 do_init_module+0x5c/0x260 __do_sys_init_module+0x14f/0x170 do_syscall_64+0x5b/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... Error appears when some i2c device driver tries to probe for devices using adapter registered by `smu_v11_0_i2c_eeprom_control_init()`. Code supporting this adapter requires `adev->psp.ras.ras` to be not NULL, which is true only when `amdgpu_ras_init()` detects HW support by calling `amdgpu_ras_check_supported()`. Before 9015d60c9ee1, adapter was registered by -> amdgpu_device_ip_init() -> amdgpu_ras_recovery_init() -> amdgpu_ras_eeprom_init() -> smu_v11_0_i2c_eeprom_control_init() after verifying that `adev->psp.ras.ras` is not NULL in `amdgpu_ras_recovery_init()`. Currently it is registered unconditionally by -> amdgpu_device_ip_init() -> pp_sw_init() -> hwmgr_sw_init() -> vega20_smu_init() -> smu_v11_0_i2c_eeprom_control_init() Fix simply adds HW support check (ras == NULL => no support) before calling `smu_v11_0_i2c_eeprom_control_{init,fini}()`. Please note that there is a chance that similar fix is also required for CHIP_ARCTURUS. I do not know whether any actual Arcturus hardware without RAS exist, and whether calling `smu_i2c_eeprom_init()` makes any sense when there is no HW support. Cc: [email protected] Fixes: 9015d60c9ee1 ("drm/amdgpu: Move EEPROM I2C adapter to amdgpu_device") Signed-off-by: Ivan Mironov <[email protected]> Tested-by: Bjorn Nostvold <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-06-25vfio/pci: Fix SR-IOV VF handling with MMIO blockingAlex Williamson1-1/+16
SR-IOV VFs do not implement the memory enable bit of the command register, therefore this bit is not set in config space after pci_enable_device(). This leads to an unintended difference between PF and VF in hand-off state to the user. We can correct this by setting the initial value of the memory enable bit in our virtualized config space. There's really no need however to ever fault a user on a VF though as this would only indicate an error in the user's management of the enable bit, versus a PF where the same access could trigger hardware faults. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Alex Williamson <[email protected]>
2020-06-25Merge tag 's390-5.8-3' of ↵Linus Torvalds3-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Fix kernel crash on system call single stepping. - Make sure early program check handler is executed with DAT on to avoid an endless program check loop. - Add __GFP_NOWARN flag to debug feature to avoid user triggerable allocation failure messages. * tag 's390-5.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/debug: avoid kernel warning on too large number of pages s390/kasan: fix early pgm check handler execution s390: fix system call single stepping
2020-06-25Merge tag 'sound-5.8-rc3' of ↵Linus Torvalds35-160/+347
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes gathered in the last two weeks. The major changes here are fixes for the recent DPCM regressions found on i.MX and Qualcomm platforms and fixes for resource leaks in ASoC DAI registrations. Other than those are mostly device-specific fixes including the usual USB- and HD-audio quirks, and a fix for syzkaller case and ID updates for new Intel platforms" * tag 'sound-5.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (32 commits) ALSA: usb-audio: Fix OOB access of mixer element list ALSA: usb-audio: add quirk for Samsung USBC Headset (AKG) ALSA: usb-audio: Add registration quirk for Kingston HyperX Cloud Flight S ASoC: rockchip: Fix a reference count leak. ASoC: amd: closing specific instance. ALSA: hda: Intel: add missing PCI IDs for ICL-H, TGL-H and EKL ASoC: hdac_hda: fix memleak with regmap not freed on remove ASoC: SOF: Intel: add PCI IDs for ICL-H and TGL-H ASoC: SOF: Intel: add PCI ID for CometLake-S ASoC: Intel: SOF: merge COMETLAKE_LP and COMETLAKE_H ALSA: hda/realtek: Add mute LED and micmute LED support for HP systems ALSA: usb-audio: Fix potential use-after-free of streams ALSA: hda/realtek - Add quirk for MSI GE63 laptop ASoC: fsl_ssi: Fix bclk calculation for mono channel ASoC: SOF: Intel: hda: Clear RIRB status before reading WP ASoC: rt1015: Update rt1015 default register value according to spec modification. ASoC: qcom: common: set correct directions for dailinks ASoc: q6afe: add support to get port direction ASoC: soc-pcm: fix checks for multi-cpu FE dailinks ASoC: rt5682: Let dai clks be registered whether mclk exists or not ...
2020-06-25rcu: Fixup noinstr warningsPeter Zijlstra2-8/+26
A KCSAN build revealed we have explicit annoations through atomic_*() usage, switch to arch_atomic_*() for the respective functions. vmlinux.o: warning: objtool: rcu_nmi_exit()+0x4d: call to __kcsan_check_access() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x25: call to __kcsan_check_access() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_nmi_enter()+0x4f: call to __kcsan_check_access() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0x2a: call to __kcsan_check_access() leaves .noinstr.text section vmlinux.o: warning: objtool: __rcu_is_watching()+0x25: call to __kcsan_check_access() leaves .noinstr.text section Additionally, without the NOP in instrumentation_begin(), objtool would not detect the lack of the 'else instrumentation_begin();' branch in rcu_nmi_enter(). Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2020-06-25locking/atomics: Provide the arch_atomic_ interface to generic codePeter Zijlstra2-1/+266
Architectures with instrumented (KASAN/KCSAN) atomic operations natively provide arch_atomic_ variants that are not instrumented. It turns out that some generic code also requires arch_atomic_ in order to avoid instrumentation, so provide the arch_atomic_ interface as a direct map into the regular atomic_ interface for non-instrumented architectures. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2020-06-25spi: pxa2xx: Add support for Intel Tiger Lake PCH-HJarkko Nikula1-0/+5
Add Intel Tiger Lake PCH-H PCI IDs. Signed-off-by: Jarkko Nikula <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-06-25arm64: perf: Report the PC value in REGS_ABI_32 modeJiping Ma1-3/+22
A 32-bit perf querying the registers of a compat task using REGS_ABI_32 will receive zeroes from w15, when it expects to find the PC. Return the PC value for register dwarf register 15 when returning register values for a compat task to perf. Cc: <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Jiping Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] [will: Shuffled code and added a comment] Signed-off-by: Will Deacon <[email protected]>
2020-06-25io_uring: fix current->mm NULL dereference on exitPavel Begunkov1-0/+9
Don't reissue requests from io_iopoll_reap_events(), the task may not have mm, which ends up with NULL. It's better to kill everything off on exit anyway. [ 677.734670] RIP: 0010:io_iopoll_complete+0x27e/0x630 ... [ 677.734679] Call Trace: [ 677.734695] ? __send_signal+0x1f2/0x420 [ 677.734698] ? _raw_spin_unlock_irqrestore+0x24/0x40 [ 677.734699] ? send_signal+0xf5/0x140 [ 677.734700] io_iopoll_getevents+0x12f/0x1a0 [ 677.734702] io_iopoll_reap_events.part.0+0x5e/0xa0 [ 677.734703] io_ring_ctx_wait_and_kill+0x132/0x1c0 [ 677.734704] io_uring_release+0x20/0x30 [ 677.734706] __fput+0xcd/0x230 [ 677.734707] ____fput+0xe/0x10 [ 677.734709] task_work_run+0x67/0xa0 [ 677.734710] do_exit+0x35d/0xb70 [ 677.734712] do_group_exit+0x43/0xa0 [ 677.734713] get_signal+0x140/0x900 [ 677.734715] do_signal+0x37/0x780 [ 677.734717] ? enqueue_hrtimer+0x41/0xb0 [ 677.734718] ? recalibrate_cpu_khz+0x10/0x10 [ 677.734720] ? ktime_get+0x3e/0xa0 [ 677.734721] ? lapic_next_deadline+0x26/0x30 [ 677.734723] ? tick_program_event+0x4d/0x90 [ 677.734724] ? __hrtimer_get_next_event+0x4d/0x80 [ 677.734726] __prepare_exit_to_usermode+0x126/0x1c0 [ 677.734741] prepare_exit_to_usermode+0x9/0x40 [ 677.734742] idtentry_exit_cond_rcu+0x4c/0x60 [ 677.734743] sysvec_reschedule_ipi+0x92/0x160 [ 677.734744] ? asm_sysvec_reschedule_ipi+0xa/0x20 [ 677.734745] asm_sysvec_reschedule_ipi+0x12/0x20 Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-06-25io_uring: fix hanging iopoll in case of -EAGAINPavel Begunkov1-7/+2
io_do_iopoll() won't do anything with a request unless req->iopoll_completed is set. So io_complete_rw_iopoll() has to set it, otherwise io_do_iopoll() will poll a file again and again even though the request of interest was completed long time ago. Also, remove -EAGAIN check from io_issue_sqe() as it races with the changed lines. The request will take the long way and be resubmitted from io_iopoll*(). io_kiocb's result and iopoll_completed") Fixes: bbde017a32b3 ("io_uring: add memory barrier to synchronize Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-06-25cpuidle: Rearrange s2idle-specific idle state entry codeRafael J. Wysocki2-7/+14
Implement call_cpuidle_s2idle() in analogy with call_cpuidle() for the s2idle-specific idle state entry and invoke it from cpuidle_idle_call() to make the s2idle-specific idle entry code path look more similar to the "regular" idle entry one. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Chen Yu <[email protected]>
2020-06-25x86/entry: Fix #UD vs WARN morePeter Zijlstra1-34/+38
vmlinux.o: warning: objtool: exc_invalid_op()+0x47: call to probe_kernel_read() leaves .noinstr.text section Since we use UD2 as a short-cut for 'CALL __WARN', treat it as such. Have the bare exception handler do the report_bug() thing. Fixes: 15a416e8aaa7 ("x86/entry: Treat BUG/WARN as NMI-like entries") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-06-25x86/entry: Increase entry_stack size to a full pagePeter Zijlstra1-1/+1
Marco crashed in bad_iret with a Clang11/KCSAN build due to overflowing the stack. Now that we run C code on it, expand it to a full page. Suggested-by: Andy Lutomirski <[email protected]> Reported-by: Marco Elver <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Lai Jiangshan <[email protected]> Tested-by: Marco Elver <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-06-25x86/entry: Fixup bad_iret vs noinstrPeter Zijlstra2-3/+7
vmlinux.o: warning: objtool: fixup_bad_iret()+0x8e: call to memcpy() leaves .noinstr.text section Worse, when KASAN there is no telling what memcpy() actually is. Force the use of __memcpy() which is our assmebly implementation. Reported-by: Marco Elver <[email protected]> Suggested-by: Marco Elver <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Marco Elver <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-06-25objtool: Don't consider vmlinux a C-filePeter Zijlstra1-1/+1
Avoids issuing C-file warnings for vmlinux. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-06-25kasan: Fix required compiler versionMarco Elver1-1/+1
The first working GCC version to satisfy CC_HAS_WORKING_NOSANITIZE_ADDRESS is GCC 8.3.0. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Marco Elver <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-06-25kdb: Make kdb_printf() console handling more robustSumit Garg1-0/+11
While rounding up CPUs via NMIs, its possible that a rounded up CPU maybe holding a console port lock leading to kgdb master CPU stuck in a deadlock during invocation of console write operations. A similar deadlock could also be possible while using synchronous breakpoints. So in order to avoid such a deadlock, set oops_in_progress to encourage the console drivers to disregard their internal spin locks: in the current calling context the risk of deadlock is a bigger problem than risks due to re-entering the console driver. We operate directly on oops_in_progress rather than using bust_spinlocks() because the calls bust_spinlocks() makes on exit are not appropriate for this calling context. Suggested-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Sumit Garg <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Thompson <[email protected]>
2020-06-25kdb: Check status of console prior to invoking handlersSumit Garg1-0/+2
Check if a console is enabled prior to invoking corresponding write handler. Suggested-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Sumit Garg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Thompson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.