]> git.proxmox.com Git - mirror_ubuntu-focal-kernel.git/log
mirror_ubuntu-focal-kernel.git
4 years agomac80211: mesh: Free pending skb when destroying a mpath
Remi Pommarel [Sat, 4 Jul 2020 13:54:19 +0000 (15:54 +0200)]
mac80211: mesh: Free pending skb when destroying a mpath

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 5e43540c2af0a0c0a18e39579b1ad49541f87506 ]

A mpath object can hold reference on a list of skb that are waiting for
mpath resolution to be sent. When destroying a mpath this skb list
should be cleaned up in order to not leak memory.

Fixing that kind of leak:

unreferenced object 0xffff0000181c9300 (size 1088):
  comm "openvpn", pid 1782, jiffies 4295071698 (age 80.416s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 f9 80 36 00 00 00 00 00  ..........6.....
    02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
  backtrace:
    [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
    [<000000002caaef13>] sk_prot_alloc.isra.39+0x34/0x178
    [<00000000ceeaa916>] sk_alloc+0x34/0x228
    [<00000000ca1f1d04>] inet_create+0x198/0x518
    [<0000000035626b1c>] __sock_create+0x134/0x328
    [<00000000a12b3a87>] __sys_socket+0xb0/0x158
    [<00000000ff859f23>] __arm64_sys_socket+0x40/0x58
    [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
    [<0000000005b5157d>] el0_svc+0x8/0xc
unreferenced object 0xffff000012973a40 (size 216):
  comm "openvpn", pid 1782, jiffies 4295082137 (age 38.660s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 c0 06 16 00 00 ff ff 00 93 1c 18 00 00 ff ff  ................
  backtrace:
    [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
    [<0000000023c8c8f9>] __alloc_skb+0xc0/0x2b8
    [<000000007ad950bb>] alloc_skb_with_frags+0x60/0x320
    [<00000000ef90023a>] sock_alloc_send_pskb+0x388/0x3c0
    [<00000000104fb1a3>] sock_alloc_send_skb+0x1c/0x28
    [<000000006919d2dd>] __ip_append_data+0xba4/0x11f0
    [<0000000083477587>] ip_make_skb+0x14c/0x1a8
    [<0000000024f3d592>] udp_sendmsg+0xaf0/0xcf0
    [<000000005aabe255>] inet_sendmsg+0x5c/0x80
    [<000000008651ea08>] __sys_sendto+0x15c/0x218
    [<000000003505c99b>] __arm64_sys_sendto+0x74/0x90
    [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
    [<0000000005b5157d>] el0_svc+0x8/0xc

Fixes: 2bdaf386f99c (mac80211: mesh: move path tables into if_mesh)
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Link: https://lore.kernel.org/r/20200704135419.27703-1-repk@triplefau.lt
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomac80211: mesh: Free ie data when leaving mesh
Remi Pommarel [Sat, 4 Jul 2020 13:50:07 +0000 (15:50 +0200)]
mac80211: mesh: Free ie data when leaving mesh

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 6a01afcf8468d3ca2bd8bbb27503f60dcf643b20 ]

At ieee80211_join_mesh() some ie data could have been allocated (see
copy_mesh_setup()) and need to be cleaned up when leaving the mesh.

This fixes the following kmemleak report:

unreferenced object 0xffff0000116bc600 (size 128):
  comm "wpa_supplicant", pid 608, jiffies 4294898983 (age 293.484s)
  hex dump (first 32 bytes):
    30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00  0...............
    00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00  .........e@.....
  backtrace:
    [<00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
    [<00000000a349dbe1>] kmemdup+0x28/0x50
    [<0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
    [<00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
    [<0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
    [<0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
    [<00000000b1bd936d>] genl_rcv_msg+0x78/0x108
    [<0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
    [<0000000011af8ec9>] genl_rcv+0x34/0x48
    [<0000000069e41f53>] netlink_unicast+0x268/0x2e8
    [<00000000a7517316>] netlink_sendmsg+0x320/0x4c0
    [<0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
    [<00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
    [<0000000037340728>] __sys_sendmsg+0xa4/0xf8
    [<000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
    [<000000001c1e5647>] el0_svc_handler+0xd0/0x1a0

Fixes: c80d545da3f7 (mac80211: Let userspace enable and configure vendor specific path selection.)
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.lt
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agobpf: Fix map leak in HASH_OF_MAPS map
Andrii Nakryiko [Wed, 29 Jul 2020 04:09:12 +0000 (21:09 -0700)]
bpf: Fix map leak in HASH_OF_MAPS map

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 1d4e1eab456e1ee92a94987499b211db05f900ea ]

Fix HASH_OF_MAPS bug of not putting inner map pointer on bpf_map_elem_update()
operation. This is due to per-cpu extra_elems optimization, which bypassed
free_htab_elem() logic doing proper clean ups. Make sure that inner map is put
properly in optimized case as well.

Fixes: 8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20200729040913.2815687-1-andriin@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoibmvnic: Fix IRQ mapping disposal in error path
Thomas Falcon [Wed, 29 Jul 2020 21:36:32 +0000 (16:36 -0500)]
ibmvnic: Fix IRQ mapping disposal in error path

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 27a2145d6f826d1fad9de06ac541b1016ced3427 ]

RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
error paths. Fix this and dispose of TX IRQ mappings correctly in
case of an error.

Fixes: ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomlxsw: core: Free EMAD transactions using kfree_rcu()
Ido Schimmel [Wed, 29 Jul 2020 09:26:46 +0000 (12:26 +0300)]
mlxsw: core: Free EMAD transactions using kfree_rcu()

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 3c8ce24b037648a5a15b85888b259a74b05ff97d ]

The lifetime of EMAD transactions (i.e., 'struct mlxsw_reg_trans') is
managed using RCU. They are freed using kfree_rcu() once the transaction
ends.

However, in case the transaction failed it is freed immediately after being
removed from the active transactions list. This is problematic because it is
still possible for a different CPU to dereference the transaction from an RCU
read-side critical section while traversing the active transaction list in
mlxsw_emad_rx_listener_func(). In which case, a use-after-free is triggered
[1].

Fix this by freeing the transaction after a grace period by calling
kfree_rcu().

[1]
BUG: KASAN: use-after-free in mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
Read of size 8 at addr ffff88800b7964e8 by task syz-executor.2/2881

CPU: 0 PID: 2881 Comm: syz-executor.2 Not tainted 5.8.0-rc4+ #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xf6/0x16e lib/dump_stack.c:118
 print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
 mlxsw_core_skb_receive+0x571/0x700 drivers/net/ethernet/mellanox/mlxsw/core.c:2061
 mlxsw_pci_cqe_rdq_handle drivers/net/ethernet/mellanox/mlxsw/pci.c:595 [inline]
 mlxsw_pci_cq_tasklet+0x12a6/0x2520 drivers/net/ethernet/mellanox/mlxsw/pci.c:651
 tasklet_action_common.isra.0+0x13f/0x3e0 kernel/softirq.c:550
 __do_softirq+0x223/0x964 kernel/softirq.c:292
 asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711
 </IRQ>
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
 do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:387 [inline]
 __irq_exit_rcu kernel/softirq.c:417 [inline]
 irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
 sysvec_apic_timer_interrupt+0x4e/0xd0 arch/x86/kernel/apic/apic.c:1091
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0x3b/0x40 kernel/locking/spinlock.c:191
Code: e8 2a c3 f4 fc 48 89 ef e8 12 96 f5 fc f6 c7 02 75 11 53 9d e8 d6 db 11 fd 65 ff 0d 1f 21 b3 56 5b 5d c3 e8 a7 d7 11 fd 53 9d <eb> ed 0f 1f 00 55 48 89 fd 65 ff 05 05 21 b3 56 ff 74 24 08 48 8d
RSP: 0018:ffff8880446ffd80 EFLAGS: 00000286
RAX: 0000000000000006 RBX: 0000000000000286 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa94ecea9
RBP: ffff888012934408 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: fffffbfff57be301 R12: 1ffff110088dffc1
R13: ffff888037b817c0 R14: ffff88802442415a R15: ffff888024424000
 __do_sys_perf_event_open+0x1b5d/0x2bd0 kernel/events/core.c:11874
 do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x473dbd
Code: Bad RIP value.
RSP: 002b:00007f21e5e9cc28 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 000000000057bf00 RCX: 0000000000473dbd
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
RBP: 000000000057bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000246 R12: 000000000057bf0c
R13: 00007ffd0493503f R14: 00000000004d0f46 R15: 00007f21e5e9cd80

Allocated by task 871:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc mm/kasan/common.c:494 [inline]
 __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
 kmalloc include/linux/slab.h:555 [inline]
 kzalloc include/linux/slab.h:669 [inline]
 mlxsw_core_reg_access_emad+0x70/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1812
 mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
 mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
 update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
 process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
 worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
 kthread+0x355/0x470 kernel/kthread.c:291
 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293

Freed by task 871:
 save_stack+0x1b/0x40 mm/kasan/common.c:48
 set_track mm/kasan/common.c:56 [inline]
 kasan_set_free_info mm/kasan/common.c:316 [inline]
 __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
 slab_free_hook mm/slub.c:1474 [inline]
 slab_free_freelist_hook mm/slub.c:1507 [inline]
 slab_free mm/slub.c:3072 [inline]
 kfree+0xe6/0x320 mm/slub.c:4052
 mlxsw_core_reg_access_emad+0xd45/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1819
 mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
 mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
 update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
 process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
 worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
 kthread+0x355/0x470 kernel/kthread.c:291
 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293

The buggy address belongs to the object at ffff88800b796400
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 232 bytes inside of
 512-byte region [ffff88800b796400ffff88800b796600)
The buggy address belongs to the page:
page:ffffea00002de500 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00002de500 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x100000000010200(slab|head)
raw: 0100000000010200 dead000000000100 dead000000000122 ffff88806c402500
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88800b796380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88800b796400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88800b796480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                          ^
 ffff88800b796500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88800b796580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Fixes: caf7297e7ab5 ("mlxsw: core: Introduce support for asynchronous EMAD register access")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomlxsw: core: Increase scope of RCU read-side critical section
Ido Schimmel [Wed, 29 Jul 2020 09:26:45 +0000 (12:26 +0300)]
mlxsw: core: Increase scope of RCU read-side critical section

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 7d8e8f3433dc8d1dc87c1aabe73a154978fb4c4d ]

The lifetime of the Rx listener item ('rxl_item') is managed using RCU,
but is dereferenced outside of RCU read-side critical section, which can
lead to a use-after-free.

Fix this by increasing the scope of the RCU read-side critical section.

Fixes: 93c1edb27f9e ("mlxsw: Introduce Mellanox switch driver core")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomlx4: disable device on shutdown
Jakub Kicinski [Fri, 24 Jul 2020 23:15:43 +0000 (16:15 -0700)]
mlx4: disable device on shutdown

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 3cab8c65525920f00d8f4997b3e9bb73aecb3a8e ]

It appears that not disabling a PCI device on .shutdown may lead to
a Hardware Error with particular (perhaps buggy) BIOS versions:

    mlx4_en: eth0: Close port called
    mlx4_en 0000:04:00.0: removed PHC
    reboot: Restarting system
    {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
    {1}[Hardware Error]: event severity: fatal
    {1}[Hardware Error]:  Error 0, type: fatal
    {1}[Hardware Error]:   section_type: PCIe error
    {1}[Hardware Error]:   port_type: 4, root port
    {1}[Hardware Error]:   version: 1.16
    {1}[Hardware Error]:   command: 0x4010, status: 0x0143
    {1}[Hardware Error]:   device_id: 0000:00:02.2
    {1}[Hardware Error]:   slot: 0
    {1}[Hardware Error]:   secondary_bus: 0x04
    {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2f06
    {1}[Hardware Error]:   class_code: 000604
    {1}[Hardware Error]:   bridge: secondary_status: 0x2000, control: 0x0003
    {1}[Hardware Error]:   aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00000000
    {1}[Hardware Error]:   aer_uncor_severity: 0x00062030
    {1}[Hardware Error]:   TLP Header: 40000018 040000ff 791f4080 00000000
[hw error repeats]
    Kernel panic - not syncing: Fatal hardware error!
    CPU: 0 PID: 2189 Comm: reboot Kdump: loaded Not tainted 5.6.x-blabla #1
    Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 05/05/2017

Fix the mlx4 driver.

This is a very similar problem to what had been fixed in:
commit 0d98ba8d70b0 ("scsi: hpsa: disable device during shutdown")
to address https://bugzilla.kernel.org/show_bug.cgi?id=199779.

Fixes: 2ba5fbd62b25 ("net/mlx4_core: Handle AER flow properly")
Reported-by: Jake Lawrence <lawja@fb.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agorhashtable: Fix unprotected RCU dereference in __rht_ptr
Herbert Xu [Fri, 24 Jul 2020 10:12:53 +0000 (20:12 +1000)]
rhashtable: Fix unprotected RCU dereference in __rht_ptr

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 1748f6a2cbc4694523f16da1c892b59861045b9d ]

The rcu_dereference call in rht_ptr_rcu is completely bogus because
we've already dereferenced the value in __rht_ptr and operated on it.
This causes potential double readings which could be fatal.  The RCU
dereference must occur prior to the comparison in __rht_ptr.

This patch changes the order of RCU dereference so that it is done
first and the result is then fed to __rht_ptr.  The RCU marking
changes have been minimised using casts which will be removed in
a follow-up patch.

Fixes: ba6306e3f648 ("rhashtable: Remove RCU marking from...")
Reported-by: "Gong, Sishuai" <sishuai@purdue.edu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet: lan78xx: fix transfer-buffer memory leak
Johan Hovold [Tue, 28 Jul 2020 12:10:30 +0000 (14:10 +0200)]
net: lan78xx: fix transfer-buffer memory leak

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 63634aa679ba8b5e306ad0727120309ae6ba8a8e ]

The interrupt URB transfer-buffer was never freed on disconnect or after
probe errors.

Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet: lan78xx: add missing endpoint sanity check
Johan Hovold [Tue, 28 Jul 2020 12:10:29 +0000 (14:10 +0200)]
net: lan78xx: add missing endpoint sanity check

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 8d8e95fd6d69d774013f51e5f2ee10c6e6d1fc14 ]

Add the missing endpoint sanity check to prevent a NULL-pointer
dereference should a malicious device lack the expected endpoints.

Note that the driver has a broken endpoint-lookup helper,
lan78xx_get_endpoints(), which can end up accepting interfaces in an
altsetting without endpoints as long as *some* altsetting has a bulk-in
and a bulk-out endpoint.

Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev
Alaa Hleihel [Wed, 15 Jul 2020 08:46:30 +0000 (11:46 +0300)]
net/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 350a63249d270b1f5bd05c7e2a24cd8de0f9db20 ]

After the cited commit, function 'mlx5_eswitch_set_vport_vlan' started
to acquire esw->state_lock.
However, esw is not defined for VF devices, hence attempting to set vf
VLANID on a VF dev will cause a kernel panic.

Fix it by moving up the (redundant) esw validation from function
'__mlx5_eswitch_set_vport_vlan' since the rest of the callers now have
and use a valid esw.

For example with vf device eth4:
 # ip link set dev eth4 vf 0 vlan 0

Trace of the panic:
 [  411.409842] BUG: unable to handle page fault for address: 00000000000011b8
 [  411.449745] #PF: supervisor read access in kernel mode
 [  411.452348] #PF: error_code(0x0000) - not-present page
 [  411.454938] PGD 80000004189c9067 P4D 80000004189c9067 PUD 41899a067 PMD 0
 [  411.458382] Oops: 0000 [#1] SMP PTI
 [  411.460268] CPU: 4 PID: 5711 Comm: ip Not tainted 5.8.0-rc4_for_upstream_min_debug_2020_07_08_22_04 #1
 [  411.462447] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
 [  411.464158] RIP: 0010:__mutex_lock+0x4e/0x940
 [  411.464928] Code: fd 41 54 49 89 f4 41 52 53 89 d3 48 83 ec 70 44 8b 1d ee 03 b0 01 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 45 85 db 75 0a <48> 3b 7f 60 0f 85 7e 05 00 00 49 8d 45 68 41 56 41 b8 01 00 00 00
 [  411.467678] RSP: 0018:ffff88841fcd74b0 EFLAGS: 00010246
 [  411.468562] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 [  411.469715] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000001158
 [  411.470812] RBP: ffff88841fcd7550 R08: ffffffffa00fa1ce R09: 0000000000000000
 [  411.471835] R10: ffff88841fcd7570 R11: 0000000000000000 R12: 0000000000000002
 [  411.472862] R13: 0000000000001158 R14: ffffffffa00fa1ce R15: 0000000000000000
 [  411.474004] FS:  00007faee7ca6b80(0000) GS:ffff88846fc00000(0000) knlGS:0000000000000000
 [  411.475237] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [  411.476129] CR2: 00000000000011b8 CR3: 000000041909c006 CR4: 0000000000360ea0
 [  411.477260] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 [  411.478340] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 [  411.479332] Call Trace:
 [  411.479760]  ? __nla_validate_parse.part.6+0x57/0x8f0
 [  411.482825]  ? mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
 [  411.483804]  mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
 [  411.484733]  mlx5e_set_vf_vlan+0x41/0x50 [mlx5_core]
 [  411.485545]  do_setlink+0x613/0x1000
 [  411.486165]  __rtnl_newlink+0x53d/0x8c0
 [  411.486791]  ? mark_held_locks+0x49/0x70
 [  411.487429]  ? __lock_acquire+0x8fe/0x1eb0
 [  411.488085]  ? rcu_read_lock_sched_held+0x52/0x60
 [  411.488998]  ? kmem_cache_alloc_trace+0x16d/0x2d0
 [  411.489759]  rtnl_newlink+0x47/0x70
 [  411.490357]  rtnetlink_rcv_msg+0x24e/0x450
 [  411.490978]  ? netlink_deliver_tap+0x92/0x3d0
 [  411.491631]  ? validate_linkmsg+0x330/0x330
 [  411.492262]  netlink_rcv_skb+0x47/0x110
 [  411.492852]  netlink_unicast+0x1ac/0x270
 [  411.493551]  netlink_sendmsg+0x336/0x450
 [  411.494209]  sock_sendmsg+0x30/0x40
 [  411.494779]  ____sys_sendmsg+0x1dd/0x1f0
 [  411.495378]  ? copy_msghdr_from_user+0x5c/0x90
 [  411.496082]  ___sys_sendmsg+0x87/0xd0
 [  411.496683]  ? lock_acquire+0xb9/0x3a0
 [  411.497322]  ? lru_cache_add+0x5/0x170
 [  411.497944]  ? find_held_lock+0x2d/0x90
 [  411.498568]  ? handle_mm_fault+0xe46/0x18c0
 [  411.499205]  ? __sys_sendmsg+0x51/0x90
 [  411.499784]  __sys_sendmsg+0x51/0x90
 [  411.500341]  do_syscall_64+0x59/0x2e0
 [  411.500938]  ? asm_exc_page_fault+0x8/0x30
 [  411.501609]  ? rcu_read_lock_sched_held+0x52/0x60
 [  411.502350]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 [  411.503093] RIP: 0033:0x7faee73b85a7
 [  411.503654] Code: Bad RIP value.

Fixes: 0e18134f4f9f ("net/mlx5e: Eswitch, use state_lock to synchronize vlan change")
Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/mlx5e: Modify uplink state on interface up/down
Ron Diskin [Sun, 5 Apr 2020 10:58:40 +0000 (13:58 +0300)]
net/mlx5e: Modify uplink state on interface up/down

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 7d0314b11cdd92bca8b89684c06953bf114605fc ]

When setting the PF interface up/down, notify the firmware to update
uplink state via MODIFY_VPORT_STATE, when E-Switch is enabled.

This behavior will prevent sending traffic out on uplink port when PF is
down, such as sending traffic from a VF interface which is still up.
Currently when calling mlx5e_open/close(), the driver only sends PAOS
command to notify the firmware to set the physical port state to
up/down, however, it is not sufficient. When VF is in "auto" state, it
follows the uplink state, which was not updated on mlx5e_open/close()
before this patch.

When switchdev mode is enabled and uplink representor is first enabled,
set the uplink port state value back to its FW default "AUTO".

Fixes: 63bfd399de55 ("net/mlx5e: Send PAOS command on interface up/down")
Signed-off-by: Ron Diskin <rondi@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/mlx5: Verify Hardware supports requested ptp function on a given pin
Eran Ben Elisha [Wed, 8 Jul 2020 08:10:01 +0000 (11:10 +0300)]
net/mlx5: Verify Hardware supports requested ptp function on a given pin

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 071995c877a8646209d55ff8edddd2b054e7424c ]

Fix a bug where driver did not verify Hardware pin capabilities for
PTP functions.

Fixes: ee7f12205abc ("net/mlx5e: Implement 1PPS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Ariel Levkovich <lariel@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/mlx5e: Fix error path of device attach
Aya Levin [Wed, 1 Jul 2020 09:21:53 +0000 (12:21 +0300)]
net/mlx5e: Fix error path of device attach

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 5cd39b6e9a420329a9a408894be7ba8aa7dd755e ]

On failure to attach the netdev, fix the rollback by re-setting the
device's state back to MLX5E_STATE_DESTROYING.

Failing to attach doesn't stop statistics polling via .ndo_get_stats64.
In this case, although the device is not attached, it falsely continues
to query the firmware for counters. Setting the device's state back to
MLX5E_STATE_DESTROYING prevents the firmware counters query.

Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/mlx5: E-switch, Destroy TSAR when fail to enable the mode
Parav Pandit [Sat, 27 Jun 2020 10:29:28 +0000 (13:29 +0300)]
net/mlx5: E-switch, Destroy TSAR when fail to enable the mode

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 2b8e9c7c3fd0e31091edb1c66cc06ffe4988ca21 ]

When either esw_legacy_enable() or esw_offloads_enable() fails,
code missed to destroy the created TSAR.

Hence, add the missing call to destroy the TSAR.

Fixes: 610090ebce92 ("net/mlx5: E-switch, Initialize TSAR Qos hardware block before its user vports")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet: hns3: fix aRFS FD rules leftover after add a user FD rule
Guojia Liao [Tue, 28 Jul 2020 02:16:51 +0000 (10:16 +0800)]
net: hns3: fix aRFS FD rules leftover after add a user FD rule

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit efe3fa45f770f1d66e2734ee7a3523c75694ff04 ]

When user had created a FD rule, all the aRFS rules should be clear up.
HNS3 process flow as below:
1.get spin lock of fd_ruls_list
2.clear up all aRFS rules
3.release lock
4.get spin lock of fd_ruls_list
5.creat a rules
6.release lock;

There is a short period of time between step 3 and step 4, which would
creatting some new aRFS FD rules if driver was receiving packet.
So refactor the fd_rule_lock to fix it.

Fixes: 441228875706 ("net: hns3: refine the flow director handle")
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet: hns3: fix a TX timeout issue
Yonglong Liu [Tue, 28 Jul 2020 02:16:49 +0000 (10:16 +0800)]
net: hns3: fix a TX timeout issue

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit a7e90ee5965fafc53d36e8b3205f08c88d7bc11f ]

When the queue depth and queue parameters are modified, there is
a low probability that TX timeout occurs. The two operations cause
the link to be down or up when the watchdog is still working. All
queues are stopped when the link is down. After the carrier is on,
all queues are woken up. If the watchdog detects the link between
the carrier on and wakeup queues, a false TX timeout occurs.

So fix this issue by modifying the sequence of carrier on and queue
wakeup, which is symmetrical to the link down action.

Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agosh: Fix validation of system call number
Michael Karcher [Wed, 22 Jul 2020 23:13:19 +0000 (01:13 +0200)]
sh: Fix validation of system call number

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 04a8a3d0a73f51c7c2da84f494db7ec1df230e69 ]

The slow path for traced system call entries accessed a wrong memory
location to get the number of the maximum allowed system call number.
Renumber the numbered "local" label for the correct location to avoid
collisions with actual local labels.

Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Fixes: f3a8308864f920d2 ("sh: Add a few missing irqflags tracing markers.")
Signed-off-by: Rich Felker <dalias@libc.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agosh/tlb: Fix PGTABLE_LEVELS > 2
Peter Zijlstra [Fri, 17 Jul 2020 11:10:07 +0000 (13:10 +0200)]
sh/tlb: Fix PGTABLE_LEVELS > 2

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit c7bcbc8ab9cb20536b8f50c62a48cebda965fdba ]

Geert reported that his SH7722-based Migo-R board failed to boot after
commit:

  c5b27a889da9 ("sh/tlb: Convert SH to generic mmu_gather")

That commit fell victim to copying the wrong pattern --
__pmd_free_tlb() used to be implemented with pmd_free().

Fixes: c5b27a889da9 ("sh/tlb: Convert SH to generic mmu_gather")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rich Felker <dalias@libc.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoselftests/net: so_txtime: fix clang issues for target arch PowerPC
Tanner Love [Mon, 27 Jul 2020 16:25:30 +0000 (12:25 -0400)]
selftests/net: so_txtime: fix clang issues for target arch PowerPC

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit b4da96ffd30bd4a305045ba5c9b0de5d4aa20dc7 ]

On powerpcle, int64_t maps to long long. Clang 9 threw:
warning: absolute value function 'labs' given an argument of type \
'long long' but has parameter of type 'long' which may cause \
truncation of value [-Wabsolute-value]
        if (labs(tstop - texpect) > cfg_variance_us)

Tested: make -C tools/testing/selftests TARGETS="net" run_tests

Fixes: af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoselftests/net: psock_fanout: fix clang issues for target arch PowerPC
Tanner Love [Mon, 27 Jul 2020 16:25:29 +0000 (12:25 -0400)]
selftests/net: psock_fanout: fix clang issues for target arch PowerPC

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 64f9ede2274980076423583683d44480909b7a40 ]

Clang 9 threw:
warning: format specifies type 'unsigned short' but the argument has \
type 'int' [-Wformat]
                typeflags, PORT_BASE, PORT_BASE + port_off);

Tested: make -C tools/testing/selftests TARGETS="net" run_tests

Fixes: 77f65ebdca50 ("packet: packet fanout rollover during socket overload")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoselftests/net: rxtimestamp: fix clang issues for target arch PowerPC
Tanner Love [Mon, 27 Jul 2020 16:25:28 +0000 (12:25 -0400)]
selftests/net: rxtimestamp: fix clang issues for target arch PowerPC

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 955cbe91bcf782c09afe369c95a20f0a4b6dcc3c ]

The signedness of char is implementation-dependent. Some systems
(including PowerPC and ARM) use unsigned char. Clang 9 threw:
warning: result of comparison of constant -1 with expression of type \
'char' is always true [-Wtautological-constant-out-of-range-compare]
                                  &arg_index)) != -1) {

Tested: make -C tools/testing/selftests TARGETS="net" run_tests

Fixes: 16e781224198 ("selftests/net: Add a test to validate behavior of rx timestamps")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonvme-tcp: fix possible hang waiting for icresp response
Sagi Grimberg [Thu, 23 Jul 2020 23:42:26 +0000 (16:42 -0700)]
nvme-tcp: fix possible hang waiting for icresp response

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit adc99fd378398f4c58798a1c57889872967d56a6 ]

If the controller died exactly when we are receiving icresp
we hang because icresp may never return. Make sure to set a
high finite limit.

Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: dts: armada-38x: fix NETA lockup when repeatedly switching speeds
Russell King [Tue, 21 Jul 2020 14:40:38 +0000 (15:40 +0100)]
ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speeds

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 09781ba0395c46b1c844f47e405e3ce7856f5989 ]

To support the change in "phy: armada-38x: fix NETA lockup when
repeatedly switching speeds" we need to update the DT with the
additional register.

Fixes: 14dc100b4411 ("phy: armada38x: add common phy support")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoxfrm: Fix crash when the hold queue is used.
Steffen Klassert [Fri, 17 Jul 2020 08:34:27 +0000 (10:34 +0200)]
xfrm: Fix crash when the hold queue is used.

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 101dde4207f1daa1fda57d714814a03835dccc3f ]

The commits "xfrm: Move dst->path into struct xfrm_dst"
and "net: Create and use new helper xfrm_dst_child()."
changed xfrm bundle handling under the assumption
that xdst->path and dst->child are not a NULL pointer
only if dst->xfrm is not a NULL pointer. That is true
with one exception. If the xfrm hold queue is used
to wait until a SA is installed by the key manager,
we create a dummy bundle without a valid dst->xfrm
pointer. The current xfrm bundle handling crashes
in that case. Fix this by extending the NULL check
of dst->xfrm with a test of the DST_XFRM_QUEUE flag.

Fixes: 0f6c480f23f4 ("xfrm: Move dst->path into struct xfrm_dst")
Fixes: b92cf4aab8e6 ("net: Create and use new helper xfrm_dst_child().")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: dts sunxi: Relax a bit the CMA pool allocation range
Maxime Ripard [Sat, 4 Jul 2020 13:08:29 +0000 (15:08 +0200)]
ARM: dts sunxi: Relax a bit the CMA pool allocation range

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 92025b90f18d45e26b7f17d68756b1abd771b9d3 ]

The hardware codec on the A10, A10s, A13 and A20 needs buffer in the
first 256MB of RAM. This was solved by setting the CMA pool at a fixed
address in that range.

However, in recent kernels there's something else that comes in and
reserve some range that end up conflicting with our default pool
requirement, and thus makes its reservation fail.

The video codec will then use buffers from the usual default pool,
outside of the range it can access, and will fail to decode anything.

Since we're only concerned about that 256MB, we can however relax the
allocation to just specify the range that's allowed, and not try to
enforce a specific address.

Fixes: 5949bc5602cc ("ARM: dts: sun4i-a10: Add Video Engine and reserved memory nodes")
Fixes: 960432010156 ("ARM: dts: sun5i: Add Video Engine and reserved memory nodes")
Fixes: c2a641a74850 ("ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200704130829.34297-1-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/x25: Fix null-ptr-deref in x25_disconnect
YueHaibing [Tue, 28 Apr 2020 08:12:08 +0000 (16:12 +0800)]
net/x25: Fix null-ptr-deref in x25_disconnect

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 8999dc89497ab1c80d0718828e838c7cd5f6bffe upstream.

We should check null before do x25_neigh_put in x25_disconnect,
otherwise may cause null-ptr-deref like this:

 #include <sys/socket.h>
 #include <linux/x25.h>

 int main() {
    int sck_x25;
    sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
    close(sck_x25);
    return 0;
 }

BUG: kernel NULL pointer dereference, address: 00000000000000d8
CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
RIP: 0010:x25_disconnect+0x91/0xe0
Call Trace:
 x25_release+0x18a/0x1b0
 __sock_release+0x3d/0xc0
 sock_close+0x13/0x20
 __fput+0x107/0x270
 ____fput+0x9/0x10
 task_work_run+0x6d/0xb0
 exit_to_usermode_loop+0x102/0x110
 do_syscall_64+0x23c/0x260
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agonet/x25: Fix x25_neigh refcnt leak when x25 disconnect
Xiyu Yang [Sat, 25 Apr 2020 13:06:25 +0000 (21:06 +0800)]
net/x25: Fix x25_neigh refcnt leak when x25 disconnect

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 4becb7ee5b3d2829ed7b9261a245a77d5b7de902 upstream.

x25_connect() invokes x25_get_neigh(), which returns a reference of the
specified x25_neigh object to "x25->neighbour" with increased refcnt.

When x25 connect success and returns, the reference still be hold by
"x25->neighbour", so the refcount should be decreased in
x25_disconnect() to keep refcount balanced.

The reference counting issue happens in x25_disconnect(), which forgets
to decrease the refcnt increased by x25_get_neigh() in x25_connect(),
causing a refcnt leak.

Fix this issue by calling x25_neigh_put() before x25_disconnect()
returns.

Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agolibtraceevent: Fix build with binutils 2.35
Ben Hutchings [Sat, 25 Jul 2020 01:06:23 +0000 (02:06 +0100)]
libtraceevent: Fix build with binutils 2.35

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 39efdd94e314336f4acbac4c07e0f37bdc3bef71 upstream.

In binutils 2.35, 'nm -D' changed to show symbol versions along with
symbol names, with the usual @@ separator.  When generating
libtraceevent-dynamic-list we need just the names, so strip off the
version suffix if present.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-trace-devel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agords: Prevent kernel-infoleak in rds_notify_queue_get()
Peilin Ye [Thu, 30 Jul 2020 19:20:26 +0000 (15:20 -0400)]
rds: Prevent kernel-infoleak in rds_notify_queue_get()

BugLink: https://bugs.launchpad.net/bugs/1891063
commit bbc8a99e952226c585ac17477a85ef1194501762 upstream.

rds_notify_queue_get() is potentially copying uninitialized kernel stack
memory to userspace since the compiler may leave a 4-byte hole at the end
of `cmsg`.

In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which
unfortunately does not always initialize that 4-byte hole. Fix it by using
memset() instead.

Cc: stable@vger.kernel.org
Fixes: f037590fff30 ("rds: fix a leak of kernel memory")
Fixes: bdbe6fbc6a2f ("RDS: recv.c")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agodrm: hold gem reference until object is no longer accessed
Steve Cohen [Mon, 20 Jul 2020 22:30:50 +0000 (18:30 -0400)]
drm: hold gem reference until object is no longer accessed

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 8490d6a7e0a0a6fab5c2d82d57a3937306660864 upstream.

A use-after-free in drm_gem_open_ioctl can happen if the
GEM object handle is closed between the idr lookup and
retrieving the size from said object since a local reference
is not being held at that point. Hold the local reference
while the object can still be accessed to fix this and
plug the potential security hole.

Signed-off-by: Steve Cohen <cohens@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1595284250-31580-1-git-send-email-cohens@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agodrm/dbi: Fix SPI Type 1 (9-bit) transfer
Paul Cercueil [Fri, 3 Jul 2020 14:13:41 +0000 (16:13 +0200)]
drm/dbi: Fix SPI Type 1 (9-bit) transfer

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 900ab59e2621053b009f707f80b2c19ce0af5dee upstream.

The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
data, the 9th (MSB) bit being the data/command bit. In order to do that,
it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
the byte corresponds to data, clears it otherwise. The 7 MSB are
padding. The array of now 16-bit values is then passed to the SPI core
for transfer.

This function was broken since its introduction, as the length of the
SPI transfer was set to the payload size before its conversion, but the
payload doubled in size due to the 8-bit -> 16-bit conversion.

Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
Cc: <stable@vger.kernel.org> # 5.4+
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200703141341.1266263-1-paul@crapouillou.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agodrm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Peilin Ye [Tue, 28 Jul 2020 19:29:24 +0000 (15:29 -0400)]
drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 upstream.

Compiler leaves a 4-byte hole near the end of `dev_info`, causing
amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
when `size` is greater than 356.

In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
unfortunately does not initialize that 4-byte hole. Fix it by using
memset() instead.

Cc: stable@vger.kernel.org
Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agodrm/amd/display: Clear dm_state for fast updates
Mazin Rezk [Mon, 27 Jul 2020 05:40:46 +0000 (05:40 +0000)]
drm/amd/display: Clear dm_state for fast updates

BugLink: https://bugs.launchpad.net/bugs/1891063
commit fde9f39ac7f1ffd799a96ffa1e06b2051f0898f1 upstream.

This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:

1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.

2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.

3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.

4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.

Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.

This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast updates")
Reported-by: Duncan <1i5t5.duncan@cox.net>
Signed-off-by: Mazin Rezk <mnrzk@protonmail.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoRevert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"
Alex Deucher [Thu, 30 Jul 2020 15:02:30 +0000 (11:02 -0400)]
Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 87004abfbc27261edd15716515d89ab42198b405 upstream.

This regressed some working configurations so revert it.  Will
fix this properly for 5.9 and backport then.

This reverts commit 38e0c89a19fd13f28d2b4721035160a3e66e270b.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agovirtio_balloon: fix up endian-ness for free cmd id
Michael S. Tsirkin [Mon, 27 Jul 2020 16:01:27 +0000 (12:01 -0400)]
virtio_balloon: fix up endian-ness for free cmd id

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 168c358af2f8c5a37f8b5f877ba2cc93995606ee upstream.

free cmd id is read using virtio endian, spec says all fields
in balloon are LE. Fix it up.

Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Wei Wang <wei.w.wang@intel.com>
Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: dts: imx6qdl-icore: Fix OTG_ID pin and sdcard detect
Michael Trimarchi [Fri, 17 Jul 2020 08:03:52 +0000 (13:33 +0530)]
ARM: dts: imx6qdl-icore: Fix OTG_ID pin and sdcard detect

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 4a601da92c2a782e5c022680d476104586b74994 upstream.

The current pin muxing scheme muxes GPIO_1 pad for USB_OTG_ID
because of which when card is inserted, usb otg is enumerated
and the card is never detected.

[   64.492645] cfg80211: failed to load regulatory.db
[   64.492657] imx-sdma 20ec000.sdma: external firmware not found, using ROM firmware
[   76.343711] ci_hdrc ci_hdrc.0: EHCI Host Controller
[   76.349742] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2
[   76.388862] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[   76.396650] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08
[   76.405412] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   76.412763] usb usb2: Product: EHCI Host Controller
[   76.417666] usb usb2: Manufacturer: Linux 5.8.0-rc1-next-20200618 ehci_hcd
[   76.424623] usb usb2: SerialNumber: ci_hdrc.0
[   76.431755] hub 2-0:1.0: USB hub found
[   76.435862] hub 2-0:1.0: 1 port detected

The TRM mentions GPIO_1 pad should be muxed/assigned for card detect
and ENET_RX_ER pad for USB_OTG_ID for proper operation.

This patch fixes pin muxing as per TRM and is tested on a
i.Core 1.5 MX6 DL SOM.

[   22.449165] mmc0: host does not support reading read-only switch, assuming write-enable
[   22.459992] mmc0: new high speed SDHC card at address 0001
[   22.469725] mmcblk0: mmc0:0001 EB1QT 29.8 GiB
[   22.478856]  mmcblk0: p1 p2

Fixes: 6df11287f7c9 ("ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: dts: imx6sx-sdb: Fix the phy-mode on fec2
Fabio Estevam [Mon, 13 Jul 2020 14:23:24 +0000 (11:23 -0300)]
ARM: dts: imx6sx-sdb: Fix the phy-mode on fec2

BugLink: https://bugs.launchpad.net/bugs/1891063
commit c696afd331be1acb39206aba53048f2386b781fc upstream.

Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
phy-mode for fec1, but missed to fix it for the fec2 node.

Fix fec2 to also use "rgmii-id" as the phy-mode.

Cc: <stable@vger.kernel.org>
Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: dts: imx6sx-sabreauto: Fix the phy-mode on fec2
Fabio Estevam [Mon, 13 Jul 2020 14:23:25 +0000 (11:23 -0300)]
ARM: dts: imx6sx-sabreauto: Fix the phy-mode on fec2

BugLink: https://bugs.launchpad.net/bugs/1891063
commit d36f260718d83928e6012247a7e1b9791cdb12ff upstream.

Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
phy-mode for fec1, but missed to fix it for the fec2 node.

Fix fec2 to also use "rgmii-id" as the phy-mode.

Cc: <stable@vger.kernel.org>
Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints
Will Deacon [Thu, 18 Jun 2020 10:16:45 +0000 (11:16 +0100)]
ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints

BugLink: https://bugs.launchpad.net/bugs/1891063
commit eec13b42d41b0f3339dcf0c4da43734427c68620 upstream.

Unprivileged memory accesses generated by the so-called "translated"
instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire
unexpectedly. In such cases, the hw_breakpoint logic will invoke the user
overflow handler which will typically raise a SIGTRAP back to the current
task. This is futile when returning back to the kernel because (a) the
signal won't have been delivered and (b) userspace can't handle the thing
anyway.

Avoid invoking the user overflow handler for watchpoints triggered by
kernel uaccess routines, and instead single-step over the faulting
instruction as we would if no overflow handler had been installed.

Cc: <stable@vger.kernel.org>
Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework")
Reported-by: Luis Machado <luis.machado@linaro.org>
Tested-by: Luis Machado <luis.machado@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agowireless: Use offsetof instead of custom macro.
Pi-Hsun Shih [Wed, 4 Dec 2019 08:13:07 +0000 (16:13 +0800)]
wireless: Use offsetof instead of custom macro.

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 6989310f5d4327e8595664954edd40a7f99ddd0d upstream.

Use offsetof to calculate offset of a field to take advantage of
compiler built-in version when possible, and avoid UBSAN warning when
compiling with Clang:

==================================================================
UBSAN: Undefined behaviour in net/wireless/wext-core.c:525:14
member access within null pointer of type 'struct iw_point'
CPU: 3 PID: 165 Comm: kworker/u16:3 Tainted: G S      W         4.19.23 #43
Workqueue: cfg80211 __cfg80211_scan_done [cfg80211]
Call trace:
 dump_backtrace+0x0/0x194
 show_stack+0x20/0x2c
 __dump_stack+0x20/0x28
 dump_stack+0x70/0x94
 ubsan_epilogue+0x14/0x44
 ubsan_type_mismatch_common+0xf4/0xfc
 __ubsan_handle_type_mismatch_v1+0x34/0x54
 wireless_send_event+0x3cc/0x470
 ___cfg80211_scan_done+0x13c/0x220 [cfg80211]
 __cfg80211_scan_done+0x28/0x34 [cfg80211]
 process_one_work+0x170/0x35c
 worker_thread+0x254/0x380
 kthread+0x13c/0x158
 ret_from_fork+0x10/0x18
===================================================================

Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20191204081307.138765-1-pihsun@chromium.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years ago9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work
Wang Hai [Fri, 12 Jun 2020 09:08:33 +0000 (17:08 +0800)]
9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29 upstream.

p9_read_work and p9_fd_cancelled may be called concurrently.
In some cases, req->req_list may be deleted by both p9_read_work
and p9_fd_cancelled.

We can fix it by ignoring replies associated with a cancelled
request and ignoring cancelled request if message has been received
before lock.

Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com
Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to "cancelled" function")
Cc: <stable@vger.kernel.org> # v3.12+
Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agovhost/scsi: fix up req type endian-ness
Michael S. Tsirkin [Fri, 10 Jul 2020 10:36:16 +0000 (06:36 -0400)]
vhost/scsi: fix up req type endian-ness

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 295c1b9852d000580786375304a9800bd9634d15 upstream.

vhost/scsi doesn't handle type conversion correctly
for request type when using virtio 1.0 and up for BE,
or cross-endian platforms.

Fix it up using vhost_32_to_cpu.

Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoIB/rdmavt: Fix RQ counting issues causing use of an invalid RWQE
Mike Marciniszyn [Tue, 28 Jul 2020 18:38:48 +0000 (14:38 -0400)]
IB/rdmavt: Fix RQ counting issues causing use of an invalid RWQE

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 54a485e9ec084da1a4b32dcf7749c7d760ed8aa5 upstream.

The lookaside count is improperly initialized to the size of the
Receive Queue with the additional +1.  In the traces below, the
RQ size is 384, so the count was set to 385.

The lookaside count is then rarely refreshed.  Note the high and
incorrect count in the trace below:

rvt_get_rwqe: [hfi1_0] wqe ffffc900078e9008 wr_id 55c7206d75a0 qpn c
qpt 2 pid 3018 num_sge 1 head 1 tail 0, count 385
rvt_get_rwqe: (hfi1_rc_rcv+0x4eb/0x1480 [hfi1] <- rvt_get_rwqe) ret=0x1

The head,tail indicate there is only one RWQE posted although the count
says 385 and we correctly return the element 0.

The next call to rvt_get_rwqe with the decremented count:

rvt_get_rwqe: [hfi1_0] wqe ffffc900078e9058 wr_id 0 qpn c
qpt 2 pid 3018 num_sge 0 head 1 tail 1, count 384
rvt_get_rwqe: (hfi1_rc_rcv+0x4eb/0x1480 [hfi1] <- rvt_get_rwqe) ret=0x1

Note that the RQ is empty (head == tail) yet we return the RWQE at tail 1,
which is not valid because of the bogus high count.

Best case, the RWQE has never been posted and the rc logic sees an RWQE
that is too small (all zeros) and puts the QP into an error state.

In the worst case, a server slow at posting receive buffers might fool
rvt_get_rwqe() into fetching an old RWQE and corrupt memory.

Fix by deleting the faulty initialization code and creating an
inline to fetch the posted count and convert all callers to use
new inline.

Fixes: f592ae3c999f ("IB/rdmavt: Fracture single lock used for posting and processing RWQEs")
Link: https://lore.kernel.org/r/20200728183848.22226.29132.stgit@awfm-01.aw.intel.com
Reported-by: Zhaojuan Guo <zguo@redhat.com>
Cc: <stable@vger.kernel.org> # 5.4.x
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Tested-by: Honggang Li <honli@redhat.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: hda/hdmi: Fix keep_power assignment for non-component devices
Takashi Iwai [Tue, 28 Jul 2020 08:20:33 +0000 (10:20 +0200)]
ALSA: hda/hdmi: Fix keep_power assignment for non-component devices

BugLink: https://bugs.launchpad.net/bugs/1891063
commit c2c3657f0aedb8736a0fb7b2b1985adfb86e7802 upstream.

It's been reported that, when neither nouveau nor Nvidia graphics
driver is used, the screen starts flickering.  And, after comparing
between the working case (stable 4.4.x) and the broken case, it turned
out that the problem comes from the audio component binding.  The
Nvidia and AMD audio binding code clears the bus->keep_power flag
whenever snd_hdac_acomp_init() succeeds.  But this doesn't mean that
the component is actually bound, but it merely indicates that it's
ready for binding.  So, when both nouveau and Nvidia are blacklisted
or not ready, the driver keeps running without the audio component but
also with bus->keep_power = false.  This made the driver runtime PM
kicked in and powering down when unused, which results in flickering
in the graphics side, as it seems.

For fixing the bug, this patch moves the bus->keep_power flag change
into generic_acomp_notifier_set() that is the function called from the
master_bind callback of component ops; i.e. it's guaranteed that the
binding succeeded.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
Fixes: 5a858e79c911 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: hda/realtek: Fix add a "ultra_low_power" function for intel reference board...
PeiSen Hou [Mon, 27 Jul 2020 11:56:47 +0000 (13:56 +0200)]
ALSA: hda/realtek: Fix add a "ultra_low_power" function for intel reference board (alc256)

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 6fa38ef1534e7e9320aa15e329eb1404ab2f70ac upstream.

Intel requires to enable power saving mode for intel reference board (alc256)

Signed-off-by: PeiSen Hou <pshou@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200727115647.10967-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: hda/realtek: typo_fix: enable headset mic of ASUS ROG Zephyrus G14(GA401) serie...
Armas Spann [Fri, 24 Jul 2020 14:08:37 +0000 (16:08 +0200)]
ALSA: hda/realtek: typo_fix: enable headset mic of ASUS ROG Zephyrus G14(GA401) series with ALC289

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 293a92c1d9913248b9987b68f3a5d6d2f0aae62b upstream.

This patch fixes a small typo I accidently submitted with the initial patch. The board should be named GA401 not G401.

Fixes: ff53664daff2 ("ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289")
Signed-off-by: Armas Spann <zappel@retarded.farm>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200724140837.302763-1-zappel@retarded.farm
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G15(GA502) series with...
Armas Spann [Fri, 24 Jul 2020 14:06:16 +0000 (16:06 +0200)]
ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G15(GA502) series with ALC289

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 4b43d05a1978a93a19374c6e6b817c9c1ff4ba4b upstream.

This patch adds support for headset mic to the ASUS ROG Zephyrus
G15(GA502) notebook series by adding the corresponding
vendor/pci_device id, as well as adding a new fixup for the used
realtek ALC289. The fixup stets the correct pin to get the headset mic
correctly recognized on audio-jack.

Signed-off-by: Armas Spann <zappel@retarded.farm>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200724140616.298892-1-zappel@retarded.farm
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: usb-audio: Add implicit feedback quirk for SSL2
Laurence Tratt [Sun, 21 Jun 2020 07:50:05 +0000 (08:50 +0100)]
ALSA: usb-audio: Add implicit feedback quirk for SSL2

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 3da87ec67a491b9633a82045896c076b794bf938 upstream.

As expected, this requires the same quirk as the SSL2+ in order for the
clock to sync. This was suggested by, and tested on an SSL2, by Dmitry.

Suggested-by: Dmitry <dpavlushko@gmail.com>
Signed-off-by: Laurence Tratt <laurie@tratt.net>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200621075005.52mjjfc6dtdjnr3h@overdrive.tratt.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomm/filemap.c: don't bother dropping mmap_sem for zero size readahead
Jan Kara [Thu, 2 Apr 2020 04:04:40 +0000 (21:04 -0700)]
mm/filemap.c: don't bother dropping mmap_sem for zero size readahead

BugLink: https://bugs.launchpad.net/bugs/1891063
commit 5c72feee3e45b40a3c96c7145ec422899d0e8964 upstream.

When handling a page fault, we drop mmap_sem to start async readahead so
that we don't block on IO submission with mmap_sem held.  However there's
no point to drop mmap_sem in case readahead is disabled.  Handle that case
to avoid pointless dropping of mmap_sem and retrying the fault.  This was
actually reported to block mlockall(MCL_CURRENT) indefinitely.

Fixes: 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking operations")
Reported-by: Minchan Kim <minchan@kernel.org>
Reported-by: Robert Stupp <snazy@gmx.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Minchan Kim <minchan@kernel.org>
Link: http://lkml.kernel.org/r/20200212101356.30759-1-jack@suse.cz
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: SeongJae Park <sjpark@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoPCI/ASPM: Disable ASPM on ASMedia ASM1083/1085 PCIe-to-PCI bridge
Robert Hancock [Wed, 22 Jul 2020 02:18:03 +0000 (20:18 -0600)]
PCI/ASPM: Disable ASPM on ASMedia ASM1083/1085 PCIe-to-PCI bridge

BugLink: https://bugs.launchpad.net/bugs/1891063
commit b361663c5a40c8bc758b7f7f2239f7a192180e7c upstream.

Recently ASPM handling was changed to allow ASPM on PCIe-to-PCI/PCI-X
bridges.  Unfortunately the ASMedia ASM1083/1085 PCIe to PCI bridge device
doesn't seem to function properly with ASPM enabled.  On an Asus PRIME
H270-PRO motherboard, it causes errors like these:

  pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
  pcieport 0000:00:1c.0: AER:   device [8086:a292] error status/mask=00003000/00002000
  pcieport 0000:00:1c.0: AER:    [12] Timeout
  pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
  pcieport 0000:00:1c.0: AER: can't find device of ID00e0

In addition to flooding the kernel log, this also causes the machine to
wake up immediately after suspend is initiated.

The device advertises ASPM L0s and L1 support in the Link Capabilities
register, but the ASMedia web page for ASM1083 [1] claims "No PCIe ASPM
support".

Windows 10 (build 2004) enables L0s, but it also logs correctable PCIe
errors.

Add a quirk to disable ASPM for this device.

[1] https://www.asmedia.com.tw/eng/e_show_products.php?cate_index=169&item=114

[bhelgaas: commit log]
Fixes: 66ff14e59e8a ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208667
Link: https://lore.kernel.org/r/20200722021803.17958-1-hancockrwd@gmail.com
Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoath10k: enable transmit data ack RSSI for QCA9884
Abhishek Ambure [Thu, 3 Oct 2019 13:45:22 +0000 (16:45 +0300)]
ath10k: enable transmit data ack RSSI for QCA9884

BugLink: https://bugs.launchpad.net/bugs/1891063
commit cc78dc3b790619aa05f22a86a9152986bd73698c upstream.

For all data packets transmitted, host gets htt tx completion event. Some QCA9984
firmware releases support WMI_SERVICE_TX_DATA_ACK_RSSI, which gives data
ack rssi values to host through htt event of data tx completion. Data ack rssi
values are valid if A0 bit is set in HTT rx message. So enable the feature also
for QCA9884.

Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00044

Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
[kvalo@codeaurora.org: improve commit log]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agosunrpc: check that domain table is empty at module unload.
Sasha Levin [Thu, 30 Jul 2020 22:55:53 +0000 (18:55 -0400)]
sunrpc: check that domain table is empty at module unload.

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit f45db2b909c7e76f35850e78f017221f30282b8e ]

The domain table should be empty at module unload.  If it isn't there is
a bug somewhere.  So check and report.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agomedia: rc: prevent memory leak in cx23888_ir_probe
Navid Emamdoost [Wed, 25 Sep 2019 15:02:41 +0000 (12:02 -0300)]
media: rc: prevent memory leak in cx23888_ir_probe

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit a7b2df76b42bdd026e3106cf2ba97db41345a177 ]

In cx23888_ir_probe if kfifo_alloc fails the allocated memory for state
should be released.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agocrypto: ccp - Release all allocated memory if sha type is invalid
Navid Emamdoost [Thu, 19 Sep 2019 16:04:48 +0000 (11:04 -0500)]
crypto: ccp - Release all allocated memory if sha type is invalid

BugLink: https://bugs.launchpad.net/bugs/1891063
[ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]

Release all allocated memory if sha type is invalid:
In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
hmac_buf should be released.

v2: fix the goto.

Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Acked-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: Ubuntu-5.4.0-47.51
Thadeu Lima de Souza Cascardo [Fri, 4 Sep 2020 19:08:25 +0000 (16:08 -0300)]
UBUNTU: Ubuntu-5.4.0-47.51

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Thadeu Lima de Souza Cascardo [Fri, 4 Sep 2020 19:06:33 +0000 (16:06 -0300)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1894315
Properties: no-test-build
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
4 years agoUBUNTU: SAUCE: net/packet: fix overflow in tpacket_rcv
Or Cohen [Fri, 4 Sep 2020 04:05:28 +0000 (21:05 -0700)]
UBUNTU: SAUCE: net/packet: fix overflow in tpacket_rcv

Using tp_reserve to calculate netoff can overflow as
tp_reserve is unsigned int and netoff is unsigned short.

This may lead to macoff receving a smaller value then
sizeof(struct virtio_net_hdr), and if po->has_vnet_hdr
is set, an out-of-bounds write will occur when
calling virtio_net_hdr_from_skb.

The bug is fixed by converting netoff to unsigned int
and checking if it exceeds USHRT_MAX.

This addresses CVE-2020-14386

Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
CVE-2020-14386
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Ian May <ian.may@canonical.com>
4 years agoUBUNTU: [Packaging] update helper scripts
Thadeu Lima de Souza Cascardo [Fri, 4 Sep 2020 18:56:18 +0000 (15:56 -0300)]
UBUNTU: [Packaging] update helper scripts

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
4 years agoUBUNTU: Start new release
Thadeu Lima de Souza Cascardo [Fri, 4 Sep 2020 18:57:56 +0000 (15:57 -0300)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
4 years agoUBUNTU: Ubuntu-5.4.0-45.49
Stefan Bader [Wed, 26 Aug 2020 13:15:46 +0000 (15:15 +0200)]
UBUNTU: Ubuntu-5.4.0-45.49

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Stefan Bader [Wed, 26 Aug 2020 13:13:58 +0000 (15:13 +0200)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1893050
Properties: no-test-build
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agopowerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
Michael Ellerman [Wed, 26 Aug 2020 01:31:00 +0000 (03:31 +0200)]
powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()

BugLink: https://bugs.launchpad.net/bugs/1888332
__init_FSCR() was added originally in commit 2468dcf641e4 ("powerpc:
Add support for context switching the TAR register") (Feb 2013), and
only set FSCR_TAR.

At that point FSCR (Facility Status and Control Register) was not
context switched, so the setting was permanent after boot.

Later we added initialisation of FSCR_DSCR to __init_FSCR(), in commit
54c9b2253d34 ("powerpc: Set DSCR bit in FSCR setup") (Mar 2013), again
that was permanent after boot.

Then commit 2517617e0de6 ("powerpc: Fix context switch DSCR on
POWER8") (Aug 2013) added a limited context switch of FSCR, just the
FSCR_DSCR bit was context switched based on thread.dscr_inherit. That
commit said "This clears the H/FSCR DSCR bit initially", but it
didn't, it left the initialisation of FSCR_DSCR in __init_FSCR().
However the initial context switch from init_task to pid 1 would clear
FSCR_DSCR because thread.dscr_inherit was 0.

That commit also introduced the requirement that FSCR_DSCR be clear
for user processes, so that we can take the facility unavailable
interrupt in order to manage dscr_inherit.

Then in commit 152d523e6307 ("powerpc: Create context switch helpers
save_sprs() and restore_sprs()") (Dec 2015) FSCR was added to
thread_struct. However it still wasn't fully context switched, we just
took the existing value and set FSCR_DSCR if the new thread had
dscr_inherit set. FSCR was still initialised at boot to FSCR_DSCR |
FSCR_TAR, but that value was not propagated into the thread_struct, so
the initial context switch set FSCR_DSCR back to 0.

Finally commit b57bd2de8c6c ("powerpc: Improve FSCR init and context
switching") (Jun 2016) added a full context switch of the FSCR, and
added an initialisation of init_task.thread.fscr to FSCR_TAR |
FSCR_EBB, but omitted FSCR_DSCR.

The end result is that swapper runs with FSCR_DSCR set because of the
initialisation in __init_FSCR(), but no other processes do, they use
the value from init_task.thread.fscr.

Having FSCR_DSCR set for swapper allows it to access SPR 3 from
userspace, but swapper never runs userspace, so it has no useful
effect. It's also confusing to have the value initialised in two
places to two different values.

So remove FSCR_DSCR from __init_FSCR(), this at least gets us to the
point where there's a single value of FSCR, even if it's still set in
two places.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Alistair Popple <alistair@popple.id.au>
Link: https://lore.kernel.org/r/20200527145843.2761782-1-mpe@ellerman.id.au
(cherry picked from commit 0828137e8f16721842468e33df0460044a0c588b)
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: Start new release
Stefan Bader [Wed, 26 Aug 2020 13:12:27 +0000 (15:12 +0200)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 years agoUBUNTU: Ubuntu-5.4.0-44.48
Kelsey Skunberg [Mon, 10 Aug 2020 20:57:15 +0000 (14:57 -0600)]
UBUNTU: Ubuntu-5.4.0-44.48

Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Kelsey Skunberg [Mon, 10 Aug 2020 20:52:32 +0000 (14:52 -0600)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1891049
Properties: no-test-build
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: Start new release
Kelsey Skunberg [Mon, 10 Aug 2020 20:49:57 +0000 (14:49 -0600)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: [Packaging] update helper scripts
Kelsey Skunberg [Mon, 10 Aug 2020 20:48:50 +0000 (14:48 -0600)]
UBUNTU: [Packaging] update helper scripts

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoxfrm: policy: match with both mark and mask on user interfaces
Xin Long [Mon, 10 Aug 2020 14:44:47 +0000 (16:44 +0200)]
xfrm: policy: match with both mark and mask on user interfaces

BugLink: https://bugs.launchpad.net/bugs/1890796
In commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
it would take 'priority' to make a policy unique, and allow duplicated
policies with different 'priority' to be added, which is not expected
by userland, as Tobias reported in strongswan.

To fix this duplicated policies issue, and also fix the issue in
commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
when doing add/del/get/update on user interfaces, this patch is to change
to look up a policy with both mark and mask by doing:

  mark.v == pol->mark.v && mark.m == pol->mark.m

and leave the check:

  (mark & pol->mark.m) == pol->mark.v

for tx/rx path only.

As the userland expects an exact mark and mask match to manage policies.

v1->v2:
  - make xfrm_policy_mark_match inline and fix the changelog as
    Tobias suggested.

Fixes: 295fae568885 ("xfrm: Allow user space manipulation of SPD mark")
Fixes: ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list")
Reported-by: Tobias Brunner <tobias@strongswan.org>
Tested-by: Tobias Brunner <tobias@strongswan.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 4f47e8ab6ab796b5380f74866fa5287aca4dcc58)
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: Ubuntu-5.4.0-43.47 Ubuntu-5.4.0-43.47
Khalid Elmously [Sat, 8 Aug 2020 06:05:57 +0000 (02:05 -0400)]
UBUNTU: Ubuntu-5.4.0-43.47

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: link-to-tracker: update tracking bug
Khalid Elmously [Sat, 8 Aug 2020 05:52:54 +0000 (01:52 -0400)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1890746
Properties: no-test-build
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoUBUNTU: update dkms package versions
Khalid Elmously [Sat, 8 Aug 2020 05:51:39 +0000 (01:51 -0400)]
UBUNTU: update dkms package versions

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoIB/mlx5: Do reverse sequence during device removal
Parav Pandit [Thu, 12 Dec 2019 11:30:21 +0000 (13:30 +0200)]
IB/mlx5: Do reverse sequence during device removal

BugLink: https://bugs.launchpad.net/bugs/1877270
When IB device profile initialization completes, device is marked as
active.

However, IB device is not marked inactive, during device removal flow. It
should be the mirror of the add flow.

Hence, mark it inactive during remove sequence.

Link: https://lore.kernel.org/r/20191212113024.336702-2-leon@kernel.org
Signed-off-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
(cherry picked from commit 4cca96a8d9da0ed8217cfdf2aec0c3c8b88e8911)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agonet/mlx5: Add devlink reload
Michael Guralnik [Sun, 27 Oct 2019 12:34:11 +0000 (14:34 +0200)]
net/mlx5: Add devlink reload

BugLink: https://bugs.launchpad.net/bugs/1877270
Implement devlink reload for mlx5.

Usage example:
devlink dev reload pci/0000:06:00.0

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
[Jeff Lane: dropped netns_change param from mlx5_devlink_reload_down
to conform to old devlink API]
(backported from commit 4383cfcc65e7879e1858da56954dae9fc20dfae9)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agonet/mlx5: Remove unneeded variable in mlx5_unload_one
zhong jiang [Thu, 12 Sep 2019 16:59:02 +0000 (00:59 +0800)]
net/mlx5: Remove unneeded variable in mlx5_unload_one

BugLink: https://bugs.launchpad.net/bugs/1877270
mlx5_unload_one do not need local variable to store different value,
Hence just remove it.

Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 32680da7103439095ba8c2dbe30c3e4d0e05e4c2)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoIB/mlx5: Load profile according to RoCE enablement state
Michael Guralnik [Fri, 8 Nov 2019 23:45:28 +0000 (23:45 +0000)]
IB/mlx5: Load profile according to RoCE enablement state

BugLink: https://bugs.launchpad.net/bugs/1877270
When RoCE is disabled load mlx5_ib in raw_eth profile.
Clean pf_profile roce capability checks as it will not be used without
roce capability.

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 94de879c28d8e6c20bfec308de84703625221712)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoIB/mlx5: Rename profile and init methods
Michael Guralnik [Fri, 8 Nov 2019 23:45:26 +0000 (23:45 +0000)]
IB/mlx5: Rename profile and init methods

BugLink: https://bugs.launchpad.net/bugs/1877270
Rename uplink_rep_profile and its unique init and cleanup stages to
suit its upcoming use as the profile when RoCE is disabled.

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit b5a498baf929a15536a4275967cf2377ad1b6015)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agonet/mlx5: Handle "enable_roce" devlink param
Michael Guralnik [Fri, 8 Nov 2019 23:45:24 +0000 (23:45 +0000)]
net/mlx5: Handle "enable_roce" devlink param

BugLink: https://bugs.launchpad.net/bugs/1877270
Register "enable_roce" param, default value is RoCE enabled.
Current configuration is stored on mlx5_core_dev and exposed to user
through the cmode runtime devlink param.
Changing configuration requires changing the cmode driverinit devlink
param and calling devlink reload.

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit cc9defcbb8fae52810f7795b039223edae51ef95)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agonet/mlx5: Document flow_steering_mode devlink param
Michael Guralnik [Fri, 8 Nov 2019 23:45:22 +0000 (23:45 +0000)]
net/mlx5: Document flow_steering_mode devlink param

BugLink: https://bugs.launchpad.net/bugs/1877270
Add documentation for current mlx5 supported devlink param.

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit e90cde0d76f01fd3b60da0a983d2e93c5c35bedc)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agodevlink: Add new "enable_roce" generic device param
Michael Guralnik [Fri, 8 Nov 2019 23:45:20 +0000 (23:45 +0000)]
devlink: Add new "enable_roce" generic device param

BugLink: https://bugs.launchpad.net/bugs/1877270
New device parameter to enable/disable handling of RoCE traffic in the
device.

Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 6c7295e13ffd5623b02f1adc1442f1d8a3d52424)
Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
4 years agoselftests/net: relax cpu affinity requirement in msg_zerocopy test
Willem de Bruijn [Thu, 6 Aug 2020 09:59:44 +0000 (10:59 +0100)]
selftests/net: relax cpu affinity requirement in msg_zerocopy test

BugLink: https://bugs.launchpad.net/bugs/1812620
The msg_zerocopy test pins the sender and receiver threads to separate
cores to reduce variance between runs.

But it hardcodes the cores and skips core 0, so it fails on machines
with the selected cores offline, or simply fewer cores.

The test mainly gives code coverage in automated runs. The throughput
of zerocopy ('-z') and non-zerocopy runs is logged for manual
inspection.

Continue even when sched_setaffinity fails. Just log to warn anyone
interpreting the data.

Fixes: 07b65c5b31ce ("test: add msg_zerocopy test")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 16f6458f2478b55e2b628797bc81a4455045c74e linux-next)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Ian May <ian.may@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agocrypto: hisilicon - update SEC driver module parameter
Longfang Liu [Tue, 4 Aug 2020 08:18:24 +0000 (16:18 +0800)]
crypto: hisilicon - update SEC driver module parameter

BugLink: https://launchpad.net/bugs/1890222
As stress-ng running SEC engine on the Ubuntu OS,
we found that SEC only supports two threads each with one TFM
based on the default module parameter 'ctx_q_num'.
If running more threads, stress-ng will fail since it cannot
get more TFMs.

In order to fix this, we adjusted the default values
of the module parameters to support more TFMs.

Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 57b1aac1b426b7255afa195298ed691ffea204c6)
Signed-off-by: Ike Panhc <ike.pan@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoRevert "UBUNTU: [Config] Disable hisi_sec2 temporarily"
Ike Panhc [Tue, 4 Aug 2020 08:18:04 +0000 (16:18 +0800)]
Revert "UBUNTU: [Config] Disable hisi_sec2 temporarily"

BugLink: https://launchpad.net/bugs/1890222
This reverts commit 951fbd63c04096369d8fc5ff3e53ddc2b2d5111b.

Signed-off-by: Ike Panhc <ike.pan@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoALSA: hda/hdmi: Add quirk to force connectivity
Kai-Heng Feng [Wed, 5 Aug 2020 13:11:48 +0000 (21:11 +0800)]
ALSA: hda/hdmi: Add quirk to force connectivity

BugLink: https://bugs.launchpad.net/bugs/1890441
HDMI on some platforms doesn't enable audio support because its Port
Connectivity [31:30] is set to AC_JACK_PORT_NONE:
Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0b000094: OUT Detect HBR HDMI DP
  Pin Default 0x58560010: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Devices: 0
  Connection: 3
     0x02 0x03* 0x04

For now, use a quirk to force connectivity based on SSID. If there are
more platforms affected by the same issue, we can eye for a more generic
solution.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200804155836.16252-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(backported from commit cd72c317a0a11f64225b9a3f1fe503bb8c7327b5 linux-next)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoPCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken
Kai-Heng Feng [Tue, 4 Aug 2020 16:08:21 +0000 (00:08 +0800)]
PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken

BugLink: https://bugs.launchpad.net/bugs/1890306
We are seeing AMD Radeon Pro W5700 doesn't work when IOMMU is enabled:

  iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=63:00.0 address=0x42b5b01a0]
  iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=63:00.0 address=0x42b5b01c0]

The error also makes graphics driver fail to probe the device.

It appears to be the same issue as commit 5e89cd303e3a ("PCI: Mark AMD
Navi14 GPU rev 0xc5 ATS as broken") addresses, and indeed the same ATS
quirk can workaround the issue.

See-also: 5e89cd303e3a ("PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken")
See-also: d28ca864c493 ("PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken")
See-also: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208725
Link: https://lore.kernel.org/r/20200728104554.28927-1-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 45beb31d3afb651bb5c41897e46bd4fa9980c51c linux-next)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: SAUCE: ASoC: amd: renoir: restore two more registers during resume
Hui Wang [Tue, 4 Aug 2020 02:03:52 +0000 (10:03 +0800)]
UBUNTU: SAUCE: ASoC: amd: renoir: restore two more registers during resume

BugLink: https://bugs.launchpad.net/bugs/1890220
Recently we found an issue about the suspend and resume. If dmic is
recording the sound, and we run suspend and resume, after the resume,
the dmic can't work well anymore. we need to close the app and reopen
the app, then the dmic could record the sound again.

For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2
-r 48000 test.wav", then suspend and resume, after the system resume
back, we speak to the dmic. then stop the arecord, use aplay to play
the test.wav, we could hear the sound recorded after resume is weird,
it is not what we speak to the dmic.

I found two registers are set in the dai_hw_params(), if the two
registers are set during the resume, this issue could be fixed.
Move the code of the dai_hw_params() into the pdm_dai_trigger(), then
these two registers will be set during resume since pdm_dai_trigger()
will be called during resume. And delete the empty function
dai_hw_params().

Signed-off-by: Hui Wang <hui.wang@canonical.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200730123138.5659-1-hui.wang@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(backported from commit ccff7bd468d5e0595176656a051ef67c01f01968
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoASoC: SOF: Intel: hda: fix generic hda codec support
Kai Vehmanen [Wed, 29 Jul 2020 04:25:55 +0000 (12:25 +0800)]
ASoC: SOF: Intel: hda: fix generic hda codec support

BugLink: https://bugs.launchpad.net/bugs/1877757
Add support for using generic codec driver with SOF. Generic driver
is used if:
 - snd_sof_intel_hda_common.hda_model="generic" is set, or
 - fallback if no other codec driver is found

The implementation is aligned with snd-hda-intel driver, and fixes audio
support for systems like Acer Swift 3 SF314-57G, on which this issue was
originally reported.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Hui Wang <hui.wang@canonical.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
BugLink: https://github.com/thesofproject/linux/issues/1807
BugLink: https://bugs.launchpad.net/bugs/1877757
Link: https://lore.kernel.org/r/20200529160358.12134-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 89d73ccab20a684d8446cea4d8ac6a2608c8d390)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: SAUCE: hda/realtek: Fix right speaker of HP laptop
Kai-Heng Feng [Wed, 29 Jul 2020 08:32:02 +0000 (16:32 +0800)]
UBUNTU: SAUCE: hda/realtek: Fix right speaker of HP laptop

BugLink: https://bugs.launchpad.net/bugs/1889375
We need to use vendor-specific COEF to pull up the AMP which can drive
the right speaker of HP laptop.

This patch is from Realtek.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: SAUCE: nvme-pci: prevent SK hynix PC400 from using Write Zeroes command
Kai-Heng Feng [Tue, 28 Jul 2020 08:45:54 +0000 (16:45 +0800)]
UBUNTU: SAUCE: nvme-pci: prevent SK hynix PC400 from using Write Zeroes command

BugLink: https://bugs.launchpad.net/bugs/1872383
After commit 6e02318eaea5 ("nvme: add support for the Write Zeroes
command"), SK hynix PC400 becomes very slow with the following error
message:

[  224.567695] blk_update_request: operation not supported error, dev nvme1n1, sector 499384320 op 0x9:(WRITE_ZEROES) flags 0x1000000 phys_seg 0 prio class 0]

SK Hynix PC400 has a buggy firmware that treats NLB as max value instead
of a range, so the NLB passed isn't a valid value to the firmware.

According to SK hynix there are three commands are affected:
- Write Zeroes
- Compare
- Write Uncorrectable

Right now only Write Zeroes is implemented, so disable it completely on
SK hynix PC400.

Cc: kyounghwan sohn <kyounghwan.sohn@sk.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
(cherry picked from commit 5611ec2b9814bc91f7b0a8d804c1fc152e2025d9 nvme/nvme-5.8)
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoASoC: amd: fixed kernel warnings
Vijendar Mukunda [Mon, 20 Jul 2020 01:58:36 +0000 (09:58 +0800)]
ASoC: amd: fixed kernel warnings

BugLink: https://bugs.launchpad.net/bugs/1887734
This patch will fix unused variables kernel warnings when
CONFIG_ACPI is disabled.

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/1594147044-25582-1-git-send-email-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit ee3d133972f1e5d260891c4dd58adb005014414a
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoASoC: amd: add ACPI dependency check
Vijendar Mukunda [Mon, 20 Jul 2020 01:58:35 +0000 (09:58 +0800)]
ASoC: amd: add ACPI dependency check

BugLink: https://bugs.launchpad.net/bugs/1887734
Add ACPI dependency for evaluating DMIC hardware
runtime.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/1594118813-18689-1-git-send-email-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 68d1abe186d1c865923d3b97414906f4697daf58
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoASoC: amd: add logic to check dmic hardware runtime
Vijendar Mukunda [Mon, 20 Jul 2020 01:58:34 +0000 (09:58 +0800)]
ASoC: amd: add logic to check dmic hardware runtime

BugLink: https://bugs.launchpad.net/bugs/1887734
Add logic to check DMIC hardware exists or not on
the platform at runtime.

Add module param for overriding DMIC hardware check
at runtime.

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/1593710826-1106-1-git-send-email-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 9e0d21e1210ffe27682a5ef71209af57f975b0d3
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: SAUCE: remove a kernel module since its name is changed
Hui Wang [Mon, 20 Jul 2020 01:56:15 +0000 (09:56 +0800)]
UBUNTU: SAUCE: remove a kernel module since its name is changed

BugLink: https://bugs.launchpad.net/bugs/1888166
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoAsoC: amd: add missing snd- module prefix to the acp3x-rn driver kernel module
Jaroslav Kysela [Mon, 20 Jul 2020 01:56:14 +0000 (09:56 +0800)]
AsoC: amd: add missing snd- module prefix to the acp3x-rn driver kernel module

BugLink: https://bugs.launchpad.net/bugs/1888166
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: vijendar.mukunda@amd.com
Cc: Alexander.Deucher@amd.com
Link: https://lore.kernel.org/r/20200625115829.791750-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit bc5c7f55f5ea91e137fc7939435ed2e2bb6e5a15)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoUBUNTU: upstream stable to v5.4.55
Kamal Mostafa [Tue, 4 Aug 2020 19:39:40 +0000 (12:39 -0700)]
UBUNTU: upstream stable to v5.4.55

BugLink: https://bugs.launchpad.net/bugs/1890343
Ignore: yes
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoLinux 5.4.55
Greg Kroah-Hartman [Fri, 31 Jul 2020 16:39:32 +0000 (18:39 +0200)]
Linux 5.4.55

BugLink: https://bugs.launchpad.net/bugs/1890343
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoRevert "dpaa_eth: fix usage as DSA master, try 3"
Vladimir Oltean [Wed, 24 Jun 2020 12:45:17 +0000 (15:45 +0300)]
Revert "dpaa_eth: fix usage as DSA master, try 3"

BugLink: https://bugs.launchpad.net/bugs/1890343
This reverts commit 40a904b1c2e57b22dd002dfce73688871cb0bac8.

The patch is not wrong, but the Fixes: tag is. It should have been:

Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
which means that it's fixing a commit which was introduced in:

git tag --contains 060ad66f97954
v5.5

which then means it should have not been backported to linux-5.4.y,
where things _were_ working and now they're not.

Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoPM: wakeup: Show statistics for deleted wakeup sources again
zhuguangqing [Mon, 9 Dec 2019 09:35:23 +0000 (17:35 +0800)]
PM: wakeup: Show statistics for deleted wakeup sources again

BugLink: https://bugs.launchpad.net/bugs/1890343
commit e976eb4b91e906f20ec25b20c152d53c472fc3fd upstream.

After commit 00ee22c28915 (PM / wakeup: Use seq_open() to show wakeup
stats), print_wakeup_source_stats(m, &deleted_ws) is not called from
wakeup_sources_stats_seq_show() any more.

Because deleted_ws is one of the wakeup sources, it should be shown
too, so add it to the end of all other wakeup sources.

Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com>
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoregmap: debugfs: check count when read regmap file
Peng Fan [Fri, 13 Mar 2020 01:58:07 +0000 (09:58 +0800)]
regmap: debugfs: check count when read regmap file

BugLink: https://bugs.launchpad.net/bugs/1890343
commit 74edd08a4fbf51d65fd8f4c7d8289cd0f392bd91 upstream.

When executing the following command, we met kernel dump.
dmesg -c > /dev/null; cd /sys;
for i in `ls /sys/kernel/debug/regmap/* -d`; do
echo "Checking regmap in $i";
cat $i/registers;
done && grep -ri "0x02d0" *;

It is because the count value is too big, and kmalloc fails. So add an
upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>
4 years agoudp: Improve load balancing for SO_REUSEPORT.
Kuniyuki Iwashima [Tue, 21 Jul 2020 06:15:31 +0000 (15:15 +0900)]
udp: Improve load balancing for SO_REUSEPORT.

BugLink: https://bugs.launchpad.net/bugs/1890343
[ Upstream commit efc6b6f6c3113e8b203b9debfb72d81e0f3dcace ]

Currently, SO_REUSEPORT does not work well if connected sockets are in a
UDP reuseport group.

Then reuseport_has_conns() returns true and the result of
reuseport_select_sock() is discarded. Also, unconnected sockets have the
same score, hence only does the first unconnected socket in udp_hslot
always receive all packets sent to unconnected sockets.

So, the result of reuseport_select_sock() should be used for load
balancing.

The noteworthy point is that the unconnected sockets placed after
connected sockets in sock_reuseport.socks will receive more packets than
others because of the algorithm in reuseport_select_sock().

    index | connected | reciprocal_scale | result
    ---------------------------------------------
    0     | no        | 20%              | 40%
    1     | no        | 20%              | 20%
    2     | yes       | 20%              | 0%
    3     | no        | 20%              | 40%
    4     | yes       | 20%              | 0%

If most of the sockets are connected, this can be a problem, but it still
works better than now.

Fixes: acdcecc61285 ("udp: correct reuseport selection with connected sockets")
CC: Willem de Bruijn <willemb@google.com>
Reviewed-by: Benjamin Herrenschmidt <benh@amazon.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>