Commit Graph

933921 Commits

Author SHA1 Message Date
Neal Cardwell
7d21d54d62 bpf: tcp: bpf_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT
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: 6de4a9c430 ("bpf: tcp: Add bpf_cubic example")
Reported-by: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:08:47 -07:00
Neal Cardwell
b344579ca8 tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT
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: ae27e98a51 ("[TCP] CUBIC v2.3")
Reported-by: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:08:47 -07:00
David S. Miller
29a30bac56 Merge branch 'Fixes-for-SJA1105-DSA-tc-gate-action'
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 <davem@davemloft.net>
2020-06-25 16:06:56 -07:00
Vladimir Oltean
43ce887c50 net: dsa: sja1105: fix tc-gate schedule with single element
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: 834f8933d5 ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links")
Reported-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:06:56 -07:00
Vladimir Oltean
82f6896a25 net: dsa: sja1105: recalculate gating subschedule after deleting tc-gate rules
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: 834f8933d5 ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:06:56 -07:00
Vladimir Oltean
026bdb2b96 net: dsa: sja1105: unconditionally free old gating config
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: 834f8933d5 ("net: dsa: sja1105: implement tc-gate using time-triggered virtual links")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:06:56 -07:00
Vladimir Oltean
e39109f596 net: dsa: sja1105: move sja1105_compose_gating_subschedule at the top
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 <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 16:06:56 -07:00
Misono Tomohiro
8b97f99222 hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
Although it rarely happens, we should call free_capabilities()
if error happens after read_capabilities() to free allocated strings.

Fixes: de584afa5e ("hwmon driver for ACPI 4.0 power meters")
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-25 16:06:06 -07:00
Weilong Chen
c17d1a3a8e fork: annotate data race in copy_process()
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: syzbot+52fced2d288f8ecd2b20@syzkaller.appspotmail.com
Signed-off-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Marco Elver <elver@google.com>
[christian.brauner@ubuntu.com: rewrite commit message]
Link: https://lore.kernel.org/r/20200623041240.154294-1-chenweilong@huawei.com
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
2020-06-26 01:05:29 +02:00
Claudiu Beznea
33fdef24c9 net: macb: free resources on failure path of at91ether_open()
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: 7897b071ac ("net: macb: convert to phylink")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 15:59:23 -07:00
Claudiu Beznea
0eaf228d57 net: macb: call pm_runtime_put_sync on failure path
Call pm_runtime_put_sync() on failure path of at91ether_open.

Fixes: e6a41c23df ("net: macb: ensure interface is not suspended on at91rm9200")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 15:59:23 -07:00
Guo Ren
e05d57dcb8
riscv: Fixup __vdso_gettimeofday broke dynamic ftrace
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: ad5d1122b8 ("riscv: use vDSO common flow to reduce the latency of the time-related functions")
Cc: stable@vger.kernel.org
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-25 15:38:39 -07:00
Eddie James
502035e284 i2c: fsi: Fix the port number field in status register
The port number field in the status register was not correct, so fix it.

Fixes: d6ffb63001 ("i2c: Add FSI-attached I2C master algorithm")
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
2020-06-26 00:25:05 +02:00
Vincent Chen
e93b327dbf
riscv: Add extern declarations for vDSO time-related functions
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 <lkp@intel.com>
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-25 15:15:51 -07:00
Vincent Chen
d0a5fdf4cc
clk: sifive: allocate sufficient memory for struct __prci_data
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: 30b8e27e3b ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block")
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-25 15:04:13 -07:00
Vincent Chen
a0fc3b3289
riscv: Add -fPIC option to CFLAGS_vgettimeofday.o
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 <lkp@intel.com>
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-25 14:58:59 -07:00
Linus Torvalds
52366a107b \n
-----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEEq1nRK9aeMoq1VSgcnJ2qBz9kQNkFAl706ikACgkQnJ2qBz9k
 QNkk/Af9E2/VzEy4CNsGWTBdxRCZQ12Q3n1pe+ReqkmQDEWjN4FxTuhukw9dtsxE
 a6ZIm9EXOyFmu+LnrSFoskWDBDCrgwo2zOF2kW/pjs9KRW04l0sWuGEI5btKW9/2
 Q/uFUJjpgrQ3sxSbj2Df0Q6k0CVBQMTzoJvH2QobViRgzoJeSMr0nE+Sw7PRHzOB
 Wh3Fis65B8ZrxBMnTPuwzo3zLrvvqtzW6MGRSK0HxOBR1R9KCWvkJgBdyMy80/tg
 bX2VvpUL6FRUmc36B1VJ/d3hon13nQ0GthTvD1FuBYHmVf/z5AU1gtQOIGl5QkWi
 Q6PoW+lL8m+gTcN29stz1KHHrvhPbQ==
 =nQGb
 -----END PGP SIGNATURE-----

Merge tag 'fsnotify_for_v5.8-rc3' of 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-25 13:02:58 -07:00
David S. Miller
f4926d513b Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
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 <davem@davemloft.net>
2020-06-25 12:52:41 -07:00
Thomas Martitz
206e732323 net: bridge: enfore alignment for ethernet address
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 6db6f0eae6 bridge: multicast to unicast

Fixes: 6db6f0eae6 ("bridge: multicast to unicast")
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Thomas Martitz <t.martitz@avm.de>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 12:38:16 -07:00
Linus Torvalds
87d93e9a91 RDMA first 5.8 rc pull request
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
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAl7023wACgkQOG33FX4g
 mxoEBg/9G8T2rSPbLIhcqnCV+qWg1v71RZ2m2IJCxJfyr0pwLQFOwfPrriH/l77w
 ROa5kPaIMjB5uZUXi1IoQqfmscgz2009HtBqzlr/ytCRTmvk5Js1SJ0uyiEhRCth
 +ZBQ4La4laniBD/Kmx9nse71dRgEDsyEbDXNQTItKJt1xuUCiUwJvB/r9KZYIM7K
 dlP15W1M6PoxapzgqNOGUfXgvJRQxVLMXk658mEPXAspolkNQE5h3bzRwdH/qvez
 g3Ar9ptceYKh2BmXHl8NGzxBYMv4tEkVofJ9gQm1QR1CS37Szrcn9ZIfa+4ON1kF
 DlIQ8RI+9KUeTExQl5an/I9LyIYSXDDvGCggPFIF9fP/fwdtKPdczM/0QQLRpEWi
 eZGwsgVmTQMiUTndfFs5Nml9WurN5K24kljj89hzojp6BtBtrZlz7bOcS1L+7YXE
 qKJ4n90dyXVdfRJ/XldY/nb1fzqmIPPzelMZOK4XGVwGNsPhmrcSueE4KlYFqWYS
 V2B7i/QjhAOUfzX3Q98+Ne6Bpn3b9tmOiTkxy5IcOhCIjto8QCW+zVHYX99M3iRX
 4uCkuVxijxq2NfMiwYaKmYmU7py/cI6Q1CAZMbYAbUwfKAYuXwqgUAQEaOqp/1Ny
 vPGBXbtE6PD+v/eKOlzXmSCEikET3payh5U5Bh5FrvKLnaKnAPI=
 =Cmfg
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

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-25 12:38:09 -07:00
Denis Kirjanov
2570284060 tcp: don't ignore ECN CWR on pure ACK
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 <denis.kirjanov@suse.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 12:20:24 -07:00
Sai Prakash Ranjan
108447fd0d arm64: Add KRYO{3,4}XX silver CPU cores to SSB safelist
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 <swboyd@chromium.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200625103123.7240-1-saiprakash.ranjan@codeaurora.org
Signed-off-by: Will Deacon <will@kernel.org>
2020-06-25 20:18:57 +01:00
Ard Biesheuvel
5a3235e50c net: phy: mscc: avoid skcipher API for single block AES encryption
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 <antoine.tenart@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Fixes: 28c5107aa9 ("net: phy: mscc: macsec support")
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-25 12:16:14 -07:00
Jens Axboe
1b52671d79 Merge branch 'nvme-5.8' of git://git.infradead.org/nvme into block-5.8
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-25 12:57:17 -06:00
Ivan Mironov
7e89e4aaa9 drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS
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 9015d60c9e, 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: stable@vger.kernel.org
Fixes: 9015d60c9e ("drm/amdgpu: Move EEPROM I2C adapter to amdgpu_device")
Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
Tested-by: Bjorn Nostvold <bjorn.nostvold@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-06-25 13:42:15 -04:00
Alex Williamson
ebfa440ce3 vfio/pci: Fix SR-IOV VF handling with MMIO blocking
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: abafbc551f ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-06-25 11:04:23 -06:00
Linus Torvalds
908f7d12d3 s390 fixes for 5.8-rc3
- 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.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEECMNfWEw3SLnmiLkZIg7DeRspbsIFAl70iiAACgkQIg7DeRsp
 bsLzEA//W/z/OagreinjUbesIK1KIRkl38w6wbYPVAfoo42+/N5NkFxTwu4e7pBF
 KE77J5c8GeBbCnHJJQaFzR9WQJuSn9j10h9Gz4gL+cvFIbwL39PMGUheZWgcBDsT
 59GIHmqYi0xO+AQbqIi2MlgKPw5lO0/U0d2XQ/NWQJiHwXI5l911jAi4B96B/pcZ
 VXxmmzB7eH9ufTrpCD6XTC9EBrSqvtBkPekxP27iFNWqutncDY1K1br4vbpWSPc3
 qyIncnekitQCjvn+cCnXEK8wwFWAsJ2ml+JhvozQVgKK278ai7YdhvsAsJb9MUXf
 SnT0QOGS2yfdWDq4Y23IVf3ff9t3wR2V3sdZYYql3An9l7QF/oHXKN3G53TGb7lY
 qtlbg8a2nC49+8g7hl/peku09iYZkPoGPhnEuWKFKNqT8q7oFpUG5aB4xZ8YtolA
 Gwuua/nafnPna83QT7tNgMrILdEyeqLYok/NE+UG1Pp67yWyQJwMqLx8U7DR3yRO
 4yMNjdYfEcYBJrGqhV6s2qeNvRphcWkedEnughgCYLlp/mfSpyXgKOIIGANCQkKk
 utwYd7UrskLrcCiAAAVWjJxMQWykpp222BytJm5noSJzepDW1lf50cl2XJaX0/7c
 sWob1lufqtZpo8SY0XHJVFLcMj75RwcWUXnYLpUQmyefbL/XDIM=
 =3+EZ
 -----END PGP SIGNATURE-----

Merge tag 's390-5.8-3' of 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-25 09:24:28 -07:00
Linus Torvalds
a4d3712b51 sound fixes for 5.8-rc3
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.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl70i2wOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE+B/A//R0mLji5hm94CaEJhX7qzOkYpH7hVHXfZfkb3
 tinAoO5uP3BRz7LilupKReluy7uyMxK1M+28HSOWSl76TjEnajBjYFTj62aCS43q
 7a4luLB2mrYeK2vd7N9y8v4tbasinQrmWeYKONk4yCnh6pbmUlaO07zqLB4LfplG
 2FO9y7c2L+8MG1fbXEvYovX6F5EagTwPKJ6J8gWGlNIvwP2NXJAS4h9jgJOXbztR
 HStSQ+CUCrkWM0WN1aaPBR+bbK40J4cChmUtRnqzWJIsZW+AwltCV7mxwfqe0p4O
 bQyxKRZf/823sgqGgM/0H/eDkKUaIppqkoJmhoSPF1QKkd0UUnDEJzVHGSgObgRp
 B5/xbzsIMdsVEyAVsTkyWVUZaYngqghbGacJpLAVQqU2sksLDxZOpksV/HWe7rfU
 S9lHQWzRVspKfneohaXsR6fs8uhg1pF+SsEXtBqeX5TlnxboM1MBHz/TmJX1+bg0
 Ucc3HiIo1tLXgnQxVYN97LEkvAclHFB8vP3wJqhAHol6TyXlsp9JwvQkiAJo6RJb
 IUSy/lCA7Wa0winbI8ExRiNElS/4MnmCotal8aIk1ltTSsOlIVDyPYyg6+dLEE8G
 +eWgingIYb3Y5AazFMbnuYOfsx4Z/bG2tnAPOP7qLBpVuGbB9Q2PfGZAFP7PpsH3
 Uke6lwI=
 =QatL
 -----END PGP SIGNATURE-----

Merge tag 'sound-5.8-rc3' of 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-25 09:15:24 -07:00
Peter Zijlstra
b58e733fd7 rcu: Fixup noinstr warnings
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) <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-06-25 08:24:32 -07:00
Peter Zijlstra
5faafd5685 locking/atomics: Provide the arch_atomic_ interface to generic code
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) <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-06-25 08:23:22 -07:00
Jarkko Nikula
cf961fce30
spi: pxa2xx: Add support for Intel Tiger Lake PCH-H
Add Intel Tiger Lake PCH-H PCI IDs.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20200625140041.745804-1-jarkko.nikula@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-25 15:50:50 +01:00
Jiping Ma
8dfe804a40 arm64: perf: Report the PC value in REGS_ABI_32 mode
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: <stable@vger.kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
Link: https://lore.kernel.org/r/1589165527-188401-1-git-send-email-jiping.ma2@windriver.com
[will: Shuffled code and added a comment]
Signed-off-by: Will Deacon <will@kernel.org>
2020-06-25 14:47:04 +01:00
Pavel Begunkov
d60b5fbc1c io_uring: fix current->mm NULL dereference on exit
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 <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-06-25 07:20:43 -06:00
Pavel Begunkov
cd664b0e35 io_uring: fix hanging iopoll in case of -EAGAIN
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: bbde017a32 ("io_uring: add memory barrier to synchronize
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-06-25 07:20:43 -06:00
Rafael J. Wysocki
10e8b11eb3 cpuidle: Rearrange s2idle-specific idle state entry code
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 <rafael.j.wysocki@intel.com>
Acked-by: Chen Yu <yu.c.chen@intel.com>
2020-06-25 13:52:53 +02:00
Peter Zijlstra
145a773aef x86/entry: Fix #UD vs WARN more
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: 15a416e8aa ("x86/entry: Treat BUG/WARN as NMI-like entries")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Link: https://lkml.kernel.org/r/20200622114713.GE577403@hirez.programming.kicks-ass.net
2020-06-25 13:45:40 +02:00
Peter Zijlstra
c7aadc0932 x86/entry: Increase entry_stack size to a full page
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 <luto@amacapital.net>
Reported-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
Tested-by: Marco Elver <elver@google.com>
Link: https://lkml.kernel.org/r/20200618144801.819246178@infradead.org
2020-06-25 13:45:40 +02:00
Peter Zijlstra
e3a9e681ad x86/entry: Fixup bad_iret vs noinstr
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 <elver@google.com>
Suggested-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Marco Elver <elver@google.com>
Link: https://lkml.kernel.org/r/20200618144801.760070502@infradead.org
2020-06-25 13:45:39 +02:00
Peter Zijlstra
734d099ba6 objtool: Don't consider vmlinux a C-file
Avoids issuing C-file warnings for vmlinux.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200618144801.701257527@infradead.org
2020-06-25 13:45:39 +02:00
Marco Elver
acf7b0bf7d kasan: Fix required compiler version
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 <sfr@canb.auug.org.au>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200623112448.GA208112@elver.google.com
2020-06-25 13:45:39 +02:00
Sumit Garg
2a78b85b70 kdb: Make kdb_printf() console handling more robust
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 <sergey.senozhatsky@gmail.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/1591264879-25920-4-git-send-email-sumit.garg@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
2020-06-25 12:04:30 +01:00
Sumit Garg
e8857288bb kdb: Check status of console prior to invoking handlers
Check if a console is enabled prior to invoking corresponding write
handler.

Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/1591264879-25920-3-git-send-email-sumit.garg@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
2020-06-25 12:04:29 +01:00
Sumit Garg
9d71b344f8 kdb: Re-factor kdb_printf() message write code
Re-factor kdb_printf() message write code in order to avoid duplication
of code and thereby increase readability.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/1591264879-25920-2-git-send-email-sumit.garg@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
2020-06-25 12:04:29 +01:00
Sumit Semwal
4ab59c3c63 dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.

I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.

The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().

In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.

In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.

Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()

Many thanks to Arnd for his FS insights :)

[1]: https://lore.kernel.org/patchwork/patch/1238278/

Fixes: bb2bb90304 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-25 16:05:40 +05:30
João H. Spies
9fbbb7ddd9 MIPS: ingenic: gcw0: Fix HP detection GPIO.
Previously marked as active high, but is in reality active low.

Cc: stable@vger.kernel.org
Fixes: b1bfdb6605 ("MIPS: ingenic: DTS: Update GCW0 support")
Signed-off-by: João H. Spies <jhlspies@gmail.com>
Tested-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-06-25 10:18:22 +02:00
Dave Airlie
5b83c25457 Merge tag 'amd-drm-fixes-5.8-2020-06-24' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
amd-drm-fixes-5.8-2020-06-24:

amdgpu:
- Fix missed mutex unlock in DC error path
- Fix firmware leak for sdma5
- DC bpc property fixes

amdkfd:
- Fix memleak in an error path

radeon:
- Fix copy paste typo in NI DPM spll validation

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200624221207.17773-1-alexander.deucher@amd.com
2020-06-25 14:51:14 +10:00
David S. Miller
eb2932b00f Merge branch 'net-bcmgenet-use-hardware-padding-of-runt-frames'
Doug Berger says:

====================
net: bcmgenet: use hardware padding of runt frames

Now that scatter-gather and tx-checksumming are enabled by default
it revealed a packet corruption issue that can occur for very short
fragmented packets.

When padding these frames to the minimum length it is possible for
the non-linear (fragment) data to be added to the end of the linear
header in an SKB. Since the number of fragments is read before the
padding and used afterward without reloading, the fragment that
should have been consumed can be tacked on in place of part of the
padding.

The third commit in this set corrects this by removing the software
padding and allowing the hardware to add the pad bytes if necessary.

The first two commits resolve warnings observed by the kbuild test
robot and are included here for simplicity of application.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-24 21:51:03 -07:00
Doug Berger
20d1f2d1b0 net: bcmgenet: use hardware padding of runt frames
When commit 474ea9cafc ("net: bcmgenet: correctly pad short
packets") added the call to skb_padto() it should have been
located before the nr_frags parameter was read since that value
could be changed when padding packets with lengths between 55
and 59 bytes (inclusive).

The use of a stale nr_frags value can cause corruption of the
pad data when tx-scatter-gather is enabled. This corruption of
the pad can cause invalid checksum computation when hardware
offload of tx-checksum is also enabled.

Since the original reason for the padding was corrected by
commit 7dd399130e ("net: bcmgenet: fix skb_len in
bcmgenet_xmit_single()") we can remove the software padding all
together and make use of hardware padding of short frames as
long as the hardware also always appends the FCS value to the
frame.

Fixes: 474ea9cafc ("net: bcmgenet: correctly pad short packets")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-24 21:51:03 -07:00
Doug Berger
d966d2efb6 net: bcmgenet: use __be16 for htons(ETH_P_IP)
The 16-bit value that holds a short in network byte order should
be declared as a restricted big endian type to allow type checks
to succeed during assignment.

Fixes: 3e37095228 ("net: bcmgenet: add support for ethtool rxnfc flows")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-24 21:51:03 -07:00
Doug Berger
673bafd5b8 net: bcmgenet: re-remove bcmgenet_hfb_add_filter
This function was originally removed by Baoyou Xie in
commit e2072600a2 ("net: bcmgenet: remove unused function in
bcmgenet.c") to prevent a build warning.

Some of the functions removed by Baoyou Xie are now used for
WAKE_FILTER support so his commit was reverted, but this function
is still unused and the kbuild test robot dutifully reported the
warning.

This commit once again removes the remaining unused hfb functions.

Fixes: 14da1510fe ("Revert "net: bcmgenet: remove unused function in bcmgenet.c"")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-24 21:51:03 -07:00