--- /dev/null
+From 1ad80c1dd2467d38b63740dbfcd6f1b7c4f6575f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Nov 2020 13:18:07 +0300
+Subject: ALSA: hda: prevent undefined shift in snd_hdac_ext_bus_get_link()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 158e1886b6262c1d1c96a18c85fac5219b8bf804 ]
+
+This is harmless, but the "addr" comes from the user and it could lead
+to a negative shift or to shift wrapping if it's too high.
+
+Fixes: 0b00a5615dc4 ("ALSA: hdac_ext: add hdac extended controller")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20201103101807.GC1127762@mwanda
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/hda/ext/hdac_ext_controller.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/hda/ext/hdac_ext_controller.c b/sound/hda/ext/hdac_ext_controller.c
+index 84b44cdae28a1..b96abebcfd1a4 100644
+--- a/sound/hda/ext/hdac_ext_controller.c
++++ b/sound/hda/ext/hdac_ext_controller.c
+@@ -156,6 +156,8 @@ struct hdac_ext_link *snd_hdac_ext_bus_get_link(struct hdac_bus *bus,
+ return NULL;
+ if (bus->idx != bus_idx)
+ return NULL;
++ if (addr < 0 || addr > 31)
++ return NULL;
+
+ list_for_each_entry(hlink, &bus->hlink_list, list) {
+ for (i = 0; i < HDA_MAX_CODECS; i++) {
+--
+2.27.0
+
--- /dev/null
+From 761614cd2b2dc39adfc813f7090ee2fdcec17c9b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 22 Sep 2020 17:27:29 +0900
+Subject: btrfs: reschedule when cloning lots of extents
+
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+
+[ Upstream commit 6b613cc97f0ace77f92f7bc112b8f6ad3f52baf8 ]
+
+We have several occurrences of a soft lockup from fstest's generic/175
+testcase, which look more or less like this one:
+
+ watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [xfs_io:10030]
+ Kernel panic - not syncing: softlockup: hung tasks
+ CPU: 0 PID: 10030 Comm: xfs_io Tainted: G L 5.9.0-rc5+ #768
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
+ Call Trace:
+ <IRQ>
+ dump_stack+0x77/0xa0
+ panic+0xfa/0x2cb
+ watchdog_timer_fn.cold+0x85/0xa5
+ ? lockup_detector_update_enable+0x50/0x50
+ __hrtimer_run_queues+0x99/0x4c0
+ ? recalibrate_cpu_khz+0x10/0x10
+ hrtimer_run_queues+0x9f/0xb0
+ update_process_times+0x28/0x80
+ tick_handle_periodic+0x1b/0x60
+ __sysvec_apic_timer_interrupt+0x76/0x210
+ asm_call_on_stack+0x12/0x20
+ </IRQ>
+ sysvec_apic_timer_interrupt+0x7f/0x90
+ asm_sysvec_apic_timer_interrupt+0x12/0x20
+ RIP: 0010:btrfs_tree_unlock+0x91/0x1a0 [btrfs]
+ RSP: 0018:ffffc90007123a58 EFLAGS: 00000282
+ RAX: ffff8881cea2fbe0 RBX: ffff8881cea2fbe0 RCX: 0000000000000000
+ RDX: ffff8881d23fd200 RSI: ffffffff82045220 RDI: ffff8881cea2fba0
+ RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000032
+ R10: 0000160000000000 R11: 0000000000001000 R12: 0000000000001000
+ R13: ffff8882357fd5b0 R14: ffff88816fa76e70 R15: ffff8881cea2fad0
+ ? btrfs_tree_unlock+0x15b/0x1a0 [btrfs]
+ btrfs_release_path+0x67/0x80 [btrfs]
+ btrfs_insert_replace_extent+0x177/0x2c0 [btrfs]
+ btrfs_replace_file_extents+0x472/0x7c0 [btrfs]
+ btrfs_clone+0x9ba/0xbd0 [btrfs]
+ btrfs_clone_files.isra.0+0xeb/0x140 [btrfs]
+ ? file_update_time+0xcd/0x120
+ btrfs_remap_file_range+0x322/0x3b0 [btrfs]
+ do_clone_file_range+0xb7/0x1e0
+ vfs_clone_file_range+0x30/0xa0
+ ioctl_file_clone+0x8a/0xc0
+ do_vfs_ioctl+0x5b2/0x6f0
+ __x64_sys_ioctl+0x37/0xa0
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ RIP: 0033:0x7f87977fc247
+ RSP: 002b:00007ffd51a2f6d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
+ RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f87977fc247
+ RDX: 00007ffd51a2f710 RSI: 000000004020940d RDI: 0000000000000003
+ RBP: 0000000000000004 R08: 00007ffd51a79080 R09: 0000000000000000
+ R10: 00005621f11352f2 R11: 0000000000000206 R12: 0000000000000000
+ R13: 0000000000000000 R14: 00005621f128b958 R15: 0000000080000000
+ Kernel Offset: disabled
+ ---[ end Kernel panic - not syncing: softlockup: hung tasks ]---
+
+All of these lockup reports have the call chain btrfs_clone_files() ->
+btrfs_clone() in common. btrfs_clone_files() calls btrfs_clone() with
+both source and destination extents locked and loops over the source
+extent to create the clones.
+
+Conditionally reschedule in the btrfs_clone() loop, to give some time back
+to other processes.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/ioctl.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
+index 01a90fa03c24f..f0e71aa05d229 100644
+--- a/fs/btrfs/ioctl.c
++++ b/fs/btrfs/ioctl.c
+@@ -4217,6 +4217,8 @@ process_slot:
+ ret = -EINTR;
+ goto out;
+ }
++
++ cond_resched();
+ }
+ ret = 0;
+
+--
+2.27.0
+
--- /dev/null
+From dc15963d8d2d6d878e6785834a1c1312af55b520 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Sep 2020 08:09:01 -0400
+Subject: btrfs: sysfs: init devices outside of the chunk_mutex
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit ca10845a56856fff4de3804c85e6424d0f6d0cde ]
+
+While running btrfs/061, btrfs/073, btrfs/078, or btrfs/178 we hit the
+following lockdep splat:
+
+ ======================================================
+ WARNING: possible circular locking dependency detected
+ 5.9.0-rc3+ #4 Not tainted
+ ------------------------------------------------------
+ kswapd0/100 is trying to acquire lock:
+ ffff96ecc22ef4a0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x330
+
+ but task is already holding lock:
+ ffffffff8dd74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #3 (fs_reclaim){+.+.}-{0:0}:
+ fs_reclaim_acquire+0x65/0x80
+ slab_pre_alloc_hook.constprop.0+0x20/0x200
+ kmem_cache_alloc+0x37/0x270
+ alloc_inode+0x82/0xb0
+ iget_locked+0x10d/0x2c0
+ kernfs_get_inode+0x1b/0x130
+ kernfs_get_tree+0x136/0x240
+ sysfs_get_tree+0x16/0x40
+ vfs_get_tree+0x28/0xc0
+ path_mount+0x434/0xc00
+ __x64_sys_mount+0xe3/0x120
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #2 (kernfs_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x7e/0x7e0
+ kernfs_add_one+0x23/0x150
+ kernfs_create_link+0x63/0xa0
+ sysfs_do_create_link_sd+0x5e/0xd0
+ btrfs_sysfs_add_devices_dir+0x81/0x130
+ btrfs_init_new_device+0x67f/0x1250
+ btrfs_ioctl+0x1ef/0x2e20
+ __x64_sys_ioctl+0x83/0xb0
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x7e/0x7e0
+ btrfs_chunk_alloc+0x125/0x3a0
+ find_free_extent+0xdf6/0x1210
+ btrfs_reserve_extent+0xb3/0x1b0
+ btrfs_alloc_tree_block+0xb0/0x310
+ alloc_tree_block_no_bg_flush+0x4a/0x60
+ __btrfs_cow_block+0x11a/0x530
+ btrfs_cow_block+0x104/0x220
+ btrfs_search_slot+0x52e/0x9d0
+ btrfs_insert_empty_items+0x64/0xb0
+ btrfs_insert_delayed_items+0x90/0x4f0
+ btrfs_commit_inode_delayed_items+0x93/0x140
+ btrfs_log_inode+0x5de/0x2020
+ btrfs_log_inode_parent+0x429/0xc90
+ btrfs_log_new_name+0x95/0x9b
+ btrfs_rename2+0xbb9/0x1800
+ vfs_rename+0x64f/0x9f0
+ do_renameat2+0x320/0x4e0
+ __x64_sys_rename+0x1f/0x30
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #0 (&delayed_node->mutex){+.+.}-{3:3}:
+ __lock_acquire+0x119c/0x1fc0
+ lock_acquire+0xa7/0x3d0
+ __mutex_lock+0x7e/0x7e0
+ __btrfs_release_delayed_node.part.0+0x3f/0x330
+ btrfs_evict_inode+0x24c/0x500
+ evict+0xcf/0x1f0
+ dispose_list+0x48/0x70
+ prune_icache_sb+0x44/0x50
+ super_cache_scan+0x161/0x1e0
+ do_shrink_slab+0x178/0x3c0
+ shrink_slab+0x17c/0x290
+ shrink_node+0x2b2/0x6d0
+ balance_pgdat+0x30a/0x670
+ kswapd+0x213/0x4c0
+ kthread+0x138/0x160
+ ret_from_fork+0x1f/0x30
+
+ other info that might help us debug this:
+
+ Chain exists of:
+ &delayed_node->mutex --> kernfs_mutex --> fs_reclaim
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(fs_reclaim);
+ lock(kernfs_mutex);
+ lock(fs_reclaim);
+ lock(&delayed_node->mutex);
+
+ *** DEADLOCK ***
+
+ 3 locks held by kswapd0/100:
+ #0: ffffffff8dd74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
+ #1: ffffffff8dd65c50 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x115/0x290
+ #2: ffff96ed2ade30e0 (&type->s_umount_key#36){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0
+
+ stack backtrace:
+ CPU: 0 PID: 100 Comm: kswapd0 Not tainted 5.9.0-rc3+ #4
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
+ Call Trace:
+ dump_stack+0x8b/0xb8
+ check_noncircular+0x12d/0x150
+ __lock_acquire+0x119c/0x1fc0
+ lock_acquire+0xa7/0x3d0
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x330
+ __mutex_lock+0x7e/0x7e0
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x330
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x330
+ ? lock_acquire+0xa7/0x3d0
+ ? find_held_lock+0x2b/0x80
+ __btrfs_release_delayed_node.part.0+0x3f/0x330
+ btrfs_evict_inode+0x24c/0x500
+ evict+0xcf/0x1f0
+ dispose_list+0x48/0x70
+ prune_icache_sb+0x44/0x50
+ super_cache_scan+0x161/0x1e0
+ do_shrink_slab+0x178/0x3c0
+ shrink_slab+0x17c/0x290
+ shrink_node+0x2b2/0x6d0
+ balance_pgdat+0x30a/0x670
+ kswapd+0x213/0x4c0
+ ? _raw_spin_unlock_irqrestore+0x41/0x50
+ ? add_wait_queue_exclusive+0x70/0x70
+ ? balance_pgdat+0x670/0x670
+ kthread+0x138/0x160
+ ? kthread_create_worker_on_cpu+0x40/0x40
+ ret_from_fork+0x1f/0x30
+
+This happens because we are holding the chunk_mutex at the time of
+adding in a new device. However we only need to hold the
+device_list_mutex, as we're going to iterate over the fs_devices
+devices. Move the sysfs init stuff outside of the chunk_mutex to get
+rid of this lockdep splat.
+
+CC: stable@vger.kernel.org # 4.4.x: f3cd2c58110dad14e: btrfs: sysfs, rename device_link add/remove functions
+CC: stable@vger.kernel.org # 4.4.x
+Reported-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/volumes.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
+index 05daa2b816c31..4067d0196556e 100644
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -2459,9 +2459,6 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
+ btrfs_set_super_num_devices(fs_info->super_copy,
+ orig_super_num_devices + 1);
+
+- /* add sysfs device entry */
+- btrfs_sysfs_add_device_link(fs_devices, device);
+-
+ /*
+ * we've got more storage, clear any full flags on the space
+ * infos
+@@ -2469,6 +2466,10 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
+ btrfs_clear_space_info_full(fs_info);
+
+ mutex_unlock(&fs_info->chunk_mutex);
++
++ /* Add sysfs device entry */
++ btrfs_sysfs_add_device_link(fs_devices, device);
++
+ mutex_unlock(&fs_devices->device_list_mutex);
+
+ if (seeding_dev) {
+--
+2.27.0
+
--- /dev/null
+From 37acaa3cc6be3ff4d1b93b5913d48b48897d4bbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Dec 2019 09:39:02 +0100
+Subject: can: can_create_echo_skb(): fix echo skb generation: always use
+ skb_clone()
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+[ Upstream commit 286228d382ba6320f04fa2e7c6fc8d4d92e428f4 ]
+
+All user space generated SKBs are owned by a socket (unless injected into the
+key via AF_PACKET). If a socket is closed, all associated skbs will be cleaned
+up.
+
+This leads to a problem when a CAN driver calls can_put_echo_skb() on a
+unshared SKB. If the socket is closed prior to the TX complete handler,
+can_get_echo_skb() and the subsequent delivering of the echo SKB to all
+registered callbacks, a SKB with a refcount of 0 is delivered.
+
+To avoid the problem, in can_get_echo_skb() the original SKB is now always
+cloned, regardless of shared SKB or not. If the process exists it can now
+safely discard its SKBs, without disturbing the delivery of the echo SKB.
+
+The problem shows up in the j1939 stack, when it clones the incoming skb, which
+detects the already 0 refcount.
+
+We can easily reproduce this with following example:
+
+testj1939 -B -r can0: &
+cansend can0 1823ff40#0123
+
+WARNING: CPU: 0 PID: 293 at lib/refcount.c:25 refcount_warn_saturate+0x108/0x174
+refcount_t: addition on 0; use-after-free.
+Modules linked in: coda_vpu imx_vdoa videobuf2_vmalloc dw_hdmi_ahb_audio vcan
+CPU: 0 PID: 293 Comm: cansend Not tainted 5.5.0-rc6-00376-g9e20dcb7040d #1
+Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
+Backtrace:
+[<c010f570>] (dump_backtrace) from [<c010f90c>] (show_stack+0x20/0x24)
+[<c010f8ec>] (show_stack) from [<c0c3e1a4>] (dump_stack+0x8c/0xa0)
+[<c0c3e118>] (dump_stack) from [<c0127fec>] (__warn+0xe0/0x108)
+[<c0127f0c>] (__warn) from [<c01283c8>] (warn_slowpath_fmt+0xa8/0xcc)
+[<c0128324>] (warn_slowpath_fmt) from [<c0539c0c>] (refcount_warn_saturate+0x108/0x174)
+[<c0539b04>] (refcount_warn_saturate) from [<c0ad2cac>] (j1939_can_recv+0x20c/0x210)
+[<c0ad2aa0>] (j1939_can_recv) from [<c0ac9dc8>] (can_rcv_filter+0xb4/0x268)
+[<c0ac9d14>] (can_rcv_filter) from [<c0aca2cc>] (can_receive+0xb0/0xe4)
+[<c0aca21c>] (can_receive) from [<c0aca348>] (can_rcv+0x48/0x98)
+[<c0aca300>] (can_rcv) from [<c09b1fdc>] (__netif_receive_skb_one_core+0x64/0x88)
+[<c09b1f78>] (__netif_receive_skb_one_core) from [<c09b2070>] (__netif_receive_skb+0x38/0x94)
+[<c09b2038>] (__netif_receive_skb) from [<c09b2130>] (netif_receive_skb_internal+0x64/0xf8)
+[<c09b20cc>] (netif_receive_skb_internal) from [<c09b21f8>] (netif_receive_skb+0x34/0x19c)
+[<c09b21c4>] (netif_receive_skb) from [<c0791278>] (can_rx_offload_napi_poll+0x58/0xb4)
+
+Fixes: 0ae89beb283a ("can: add destructor for self generated skbs")
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: http://lore.kernel.org/r/20200124132656.22156-1-o.rempel@pengutronix.de
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/can/skb.h | 20 ++++++++------------
+ 1 file changed, 8 insertions(+), 12 deletions(-)
+
+diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h
+index b3379a97245c1..a34694e675c9a 100644
+--- a/include/linux/can/skb.h
++++ b/include/linux/can/skb.h
+@@ -61,21 +61,17 @@ static inline void can_skb_set_owner(struct sk_buff *skb, struct sock *sk)
+ */
+ static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb)
+ {
+- if (skb_shared(skb)) {
+- struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
++ struct sk_buff *nskb;
+
+- if (likely(nskb)) {
+- can_skb_set_owner(nskb, skb->sk);
+- consume_skb(skb);
+- return nskb;
+- } else {
+- kfree_skb(skb);
+- return NULL;
+- }
++ nskb = skb_clone(skb, GFP_ATOMIC);
++ if (unlikely(!nskb)) {
++ kfree_skb(skb);
++ return NULL;
+ }
+
+- /* we can assume to have an unshared skb with proper owner */
+- return skb;
++ can_skb_set_owner(nskb, skb->sk);
++ consume_skb(skb);
++ return nskb;
+ }
+
+ #endif /* !_CAN_SKB_H */
+--
+2.27.0
+
--- /dev/null
+From 4c924ae8369d487b38eb391be944312c993c31c5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 20 Oct 2020 08:44:43 +0200
+Subject: can: dev: __can_get_echo_skb(): fix real payload length return value
+ for RTR frames
+
+From: Oliver Hartkopp <socketcan@hartkopp.net>
+
+[ Upstream commit ed3320cec279407a86bc4c72edc4a39eb49165ec ]
+
+The can_get_echo_skb() function returns the number of received bytes to
+be used for netdev statistics. In the case of RTR frames we get a valid
+(potential non-zero) data length value which has to be passed for further
+operations. But on the wire RTR frames have no payload length. Therefore
+the value to be used in the statistics has to be zero for RTR frames.
+
+Reported-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Link: https://lore.kernel.org/r/20201020064443.80164-1-socketcan@hartkopp.net
+Fixes: cf5046b309b3 ("can: dev: let can_get_echo_skb() return dlc of CAN frame")
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
+index be532eb64baa2..1950b13f22dfc 100644
+--- a/drivers/net/can/dev.c
++++ b/drivers/net/can/dev.c
+@@ -493,9 +493,13 @@ struct sk_buff *__can_get_echo_skb(struct net_device *dev, unsigned int idx, u8
+ */
+ struct sk_buff *skb = priv->echo_skb[idx];
+ struct canfd_frame *cf = (struct canfd_frame *)skb->data;
+- u8 len = cf->len;
+
+- *len_ptr = len;
++ /* get the real payload length for netdev statistics */
++ if (cf->can_id & CAN_RTR_FLAG)
++ *len_ptr = 0;
++ else
++ *len_ptr = cf->len;
++
+ priv->echo_skb[idx] = NULL;
+
+ return skb;
+--
+2.27.0
+
--- /dev/null
+From 644047adc0e717115dae8e2fa527e1c3bb4dffb7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 3 Oct 2020 00:41:45 +0900
+Subject: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ
+ context
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 2283f79b22684d2812e5c76fc2280aae00390365 ]
+
+If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
+not always, the case), the 'WARN_ON(in_irq)' in
+net/core/skbuff.c#skb_release_head_state() might be triggered, under network
+congestion circumstances, together with the potential risk of a NULL pointer
+dereference.
+
+The root cause of this issue is the call to kfree_skb() instead of
+dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().
+
+This patch prevents the skb to be freed within the call to netif_rx() by
+incrementing its reference count with skb_get(). The skb is finally freed by
+one of the in-irq-context safe functions: dev_consume_skb_any() or
+dev_kfree_skb_any(). The "any" version is used because some drivers might call
+can_get_echo_skb() in a normal context.
+
+The reason for this issue to occur is that initially, in the core network
+stack, loopback skb were not supposed to be received in hardware IRQ context.
+The CAN stack is an exeption.
+
+This bug was previously reported back in 2017 in [1] but the proposed patch
+never got accepted.
+
+While [1] directly modifies net/core/dev.c, we try to propose here a
+smoother modification local to CAN network stack (the assumption
+behind is that only CAN devices are affected by this issue).
+
+[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/r/20201002154219.4887-2-mailhol.vincent@wanadoo.fr
+Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
+index 1545f2b299d06..be532eb64baa2 100644
+--- a/drivers/net/can/dev.c
++++ b/drivers/net/can/dev.c
+@@ -520,7 +520,11 @@ unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx)
+ if (!skb)
+ return 0;
+
+- netif_rx(skb);
++ skb_get(skb);
++ if (netif_rx(skb) == NET_RX_SUCCESS)
++ dev_consume_skb_any(skb);
++ else
++ dev_kfree_skb_any(skb);
+
+ return len;
+ }
+--
+2.27.0
+
--- /dev/null
+From 935b3dc53446713bae9b03c7ee5b59a909619263 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 20 Oct 2020 23:53:55 +0800
+Subject: can: flexcan: remove FLEXCAN_QUIRK_DISABLE_MECR quirk for LS1021A
+
+From: Joakim Zhang <qiangqing.zhang@nxp.com>
+
+[ Upstream commit 018799649071a1638c0c130526af36747df4355a ]
+
+After double check with Layerscape CAN owner (Pankaj Bansal), confirm that
+LS1021A doesn't support ECC feature, so remove FLEXCAN_QUIRK_DISABLE_MECR
+quirk.
+
+Fixes: 99b7668c04b27 ("can: flexcan: adding platform specific details for LS1021A")
+Cc: Pankaj Bansal <pankaj.bansal@nxp.com>
+Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
+Link: https://lore.kernel.org/r/20201020155402.30318-4-qiangqing.zhang@nxp.com
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/flexcan.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
+index 0be8db6ab3195..92fe345e48ab7 100644
+--- a/drivers/net/can/flexcan.c
++++ b/drivers/net/can/flexcan.c
+@@ -301,8 +301,7 @@ static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
+
+ static const struct flexcan_devtype_data fsl_ls1021a_r2_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
+- FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+- FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
++ FLEXCAN_QUIRK_BROKEN_PERR_STATE | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
+ };
+
+ static const struct can_bittiming_const flexcan_bittiming_const = {
+--
+2.27.0
+
--- /dev/null
+From 28054bf7735d1d7e8832e7722d6649a97d9437a5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 13 Oct 2020 17:39:47 +0200
+Subject: can: peak_canfd: pucan_handle_can_rx(): fix echo management when
+ loopback is on
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+[ Upstream commit 93ef65e5a6357cc7381f85fcec9283fe29970045 ]
+
+Echo management is driven by PUCAN_MSG_LOOPED_BACK bit, while loopback
+frames are identified with PUCAN_MSG_SELF_RECEIVE bit. Those bits are set
+for each outgoing frame written to the IP core so that a copy of each one
+will be placed into the rx path. Thus,
+
+- when PUCAN_MSG_LOOPED_BACK is set then the rx frame is an echo of a
+ previously sent frame,
+- when PUCAN_MSG_LOOPED_BACK+PUCAN_MSG_SELF_RECEIVE are set, then the rx
+ frame is an echo AND a loopback frame. Therefore, this frame must be
+ put into the socket rx path too.
+
+This patch fixes how CAN frames are handled when these are sent while the
+can interface is configured in "loopback on" mode.
+
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Link: https://lore.kernel.org/r/20201013153947.28012-1-s.grosjean@peak-system.com
+Fixes: 8ac8321e4a79 ("can: peak: add support for PEAK PCAN-PCIe FD CAN-FD boards")
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/peak_canfd/peak_canfd.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/can/peak_canfd/peak_canfd.c b/drivers/net/can/peak_canfd/peak_canfd.c
+index 5696d7e807513..4bc5d522c74bb 100644
+--- a/drivers/net/can/peak_canfd/peak_canfd.c
++++ b/drivers/net/can/peak_canfd/peak_canfd.c
+@@ -256,8 +256,7 @@ static int pucan_handle_can_rx(struct peak_canfd_priv *priv,
+ cf_len = get_can_dlc(pucan_msg_get_dlc(msg));
+
+ /* if this frame is an echo, */
+- if ((rx_msg_flags & PUCAN_MSG_LOOPED_BACK) &&
+- !(rx_msg_flags & PUCAN_MSG_SELF_RECEIVE)) {
++ if (rx_msg_flags & PUCAN_MSG_LOOPED_BACK) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->echo_lock, flags);
+@@ -271,7 +270,13 @@ static int pucan_handle_can_rx(struct peak_canfd_priv *priv,
+ netif_wake_queue(priv->ndev);
+
+ spin_unlock_irqrestore(&priv->echo_lock, flags);
+- return 0;
++
++ /* if this frame is only an echo, stop here. Otherwise,
++ * continue to push this application self-received frame into
++ * its own rx queue.
++ */
++ if (!(rx_msg_flags & PUCAN_MSG_SELF_RECEIVE))
++ return 0;
+ }
+
+ /* otherwise, it should be pushed into rx fifo */
+--
+2.27.0
+
--- /dev/null
+From f5008e5d4b0c40f205f6ebb5877efccac3a4913b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Aug 2020 17:06:04 +0300
+Subject: can: peak_usb: add range checking in decode operations
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit a6921dd524fe31d1f460c161d3526a407533b6db ]
+
+These values come from skb->data so Smatch considers them untrusted. I
+believe Smatch is correct but I don't have a way to test this.
+
+The usb_if->dev[] array has 2 elements but the index is in the 0-15
+range without checks. The cfd->len can be up to 255 but the maximum
+valid size is CANFD_MAX_DLEN (64) so that could lead to memory
+corruption.
+
+Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20200813140604.GA456946@mwanda
+Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 48 +++++++++++++++++-----
+ 1 file changed, 37 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+index 41988358f63c8..19600d35aac55 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+@@ -476,12 +476,18 @@ static int pcan_usb_fd_decode_canmsg(struct pcan_usb_fd_if *usb_if,
+ struct pucan_msg *rx_msg)
+ {
+ struct pucan_rx_msg *rm = (struct pucan_rx_msg *)rx_msg;
+- struct peak_usb_device *dev = usb_if->dev[pucan_msg_get_channel(rm)];
+- struct net_device *netdev = dev->netdev;
++ struct peak_usb_device *dev;
++ struct net_device *netdev;
+ struct canfd_frame *cfd;
+ struct sk_buff *skb;
+ const u16 rx_msg_flags = le16_to_cpu(rm->flags);
+
++ if (pucan_msg_get_channel(rm) >= ARRAY_SIZE(usb_if->dev))
++ return -ENOMEM;
++
++ dev = usb_if->dev[pucan_msg_get_channel(rm)];
++ netdev = dev->netdev;
++
+ if (rx_msg_flags & PUCAN_MSG_EXT_DATA_LEN) {
+ /* CANFD frame case */
+ skb = alloc_canfd_skb(netdev, &cfd);
+@@ -527,15 +533,21 @@ static int pcan_usb_fd_decode_status(struct pcan_usb_fd_if *usb_if,
+ struct pucan_msg *rx_msg)
+ {
+ struct pucan_status_msg *sm = (struct pucan_status_msg *)rx_msg;
+- struct peak_usb_device *dev = usb_if->dev[pucan_stmsg_get_channel(sm)];
+- struct pcan_usb_fd_device *pdev =
+- container_of(dev, struct pcan_usb_fd_device, dev);
++ struct pcan_usb_fd_device *pdev;
+ enum can_state new_state = CAN_STATE_ERROR_ACTIVE;
+ enum can_state rx_state, tx_state;
+- struct net_device *netdev = dev->netdev;
++ struct peak_usb_device *dev;
++ struct net_device *netdev;
+ struct can_frame *cf;
+ struct sk_buff *skb;
+
++ if (pucan_stmsg_get_channel(sm) >= ARRAY_SIZE(usb_if->dev))
++ return -ENOMEM;
++
++ dev = usb_if->dev[pucan_stmsg_get_channel(sm)];
++ pdev = container_of(dev, struct pcan_usb_fd_device, dev);
++ netdev = dev->netdev;
++
+ /* nothing should be sent while in BUS_OFF state */
+ if (dev->can.state == CAN_STATE_BUS_OFF)
+ return 0;
+@@ -587,9 +599,14 @@ static int pcan_usb_fd_decode_error(struct pcan_usb_fd_if *usb_if,
+ struct pucan_msg *rx_msg)
+ {
+ struct pucan_error_msg *er = (struct pucan_error_msg *)rx_msg;
+- struct peak_usb_device *dev = usb_if->dev[pucan_ermsg_get_channel(er)];
+- struct pcan_usb_fd_device *pdev =
+- container_of(dev, struct pcan_usb_fd_device, dev);
++ struct pcan_usb_fd_device *pdev;
++ struct peak_usb_device *dev;
++
++ if (pucan_ermsg_get_channel(er) >= ARRAY_SIZE(usb_if->dev))
++ return -EINVAL;
++
++ dev = usb_if->dev[pucan_ermsg_get_channel(er)];
++ pdev = container_of(dev, struct pcan_usb_fd_device, dev);
+
+ /* keep a trace of tx and rx error counters for later use */
+ pdev->bec.txerr = er->tx_err_cnt;
+@@ -603,11 +620,17 @@ static int pcan_usb_fd_decode_overrun(struct pcan_usb_fd_if *usb_if,
+ struct pucan_msg *rx_msg)
+ {
+ struct pcan_ufd_ovr_msg *ov = (struct pcan_ufd_ovr_msg *)rx_msg;
+- struct peak_usb_device *dev = usb_if->dev[pufd_omsg_get_channel(ov)];
+- struct net_device *netdev = dev->netdev;
++ struct peak_usb_device *dev;
++ struct net_device *netdev;
+ struct can_frame *cf;
+ struct sk_buff *skb;
+
++ if (pufd_omsg_get_channel(ov) >= ARRAY_SIZE(usb_if->dev))
++ return -EINVAL;
++
++ dev = usb_if->dev[pufd_omsg_get_channel(ov)];
++ netdev = dev->netdev;
++
+ /* allocate an skb to store the error frame */
+ skb = alloc_can_err_skb(netdev, &cf);
+ if (!skb)
+@@ -724,6 +747,9 @@ static int pcan_usb_fd_encode_msg(struct peak_usb_device *dev,
+ u16 tx_msg_size, tx_msg_flags;
+ u8 can_dlc;
+
++ if (cfd->len > CANFD_MAX_DLEN)
++ return -EINVAL;
++
+ tx_msg_size = ALIGN(sizeof(struct pucan_tx_msg) + cfd->len, 4);
+ tx_msg->size = cpu_to_le16(tx_msg_size);
+ tx_msg->type = cpu_to_le16(PUCAN_MSG_CAN_TX);
+--
+2.27.0
+
--- /dev/null
+From 11d60aba857b1e8092cee383736b3827b6f8459b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Oct 2020 10:56:31 +0200
+Subject: can: peak_usb: peak_usb_get_ts_time(): fix timestamp wrapping
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+[ Upstream commit ecc7b4187dd388549544195fb13a11b4ea8e6a84 ]
+
+Fabian Inostroza <fabianinostrozap@gmail.com> has discovered a potential
+problem in the hardware timestamp reporting from the PCAN-USB USB CAN interface
+(only), related to the fact that a timestamp of an event may precede the
+timestamp used for synchronization when both records are part of the same USB
+packet. However, this case was used to detect the wrapping of the time counter.
+
+This patch details and fixes the two identified cases where this problem can
+occur.
+
+Reported-by: Fabian Inostroza <fabianinostrozap@gmail.com>
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Link: https://lore.kernel.org/r/20201014085631.15128-1-s.grosjean@peak-system.com
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 51 ++++++++++++++++++--
+ 1 file changed, 46 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index afc8d978124ef..db156a11e6db5 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -138,14 +138,55 @@ void peak_usb_get_ts_time(struct peak_time_ref *time_ref, u32 ts, ktime_t *time)
+ /* protect from getting time before setting now */
+ if (ktime_to_ns(time_ref->tv_host)) {
+ u64 delta_us;
++ s64 delta_ts = 0;
++
++ /* General case: dev_ts_1 < dev_ts_2 < ts, with:
++ *
++ * - dev_ts_1 = previous sync timestamp
++ * - dev_ts_2 = last sync timestamp
++ * - ts = event timestamp
++ * - ts_period = known sync period (theoretical)
++ * ~ dev_ts2 - dev_ts1
++ * *but*:
++ *
++ * - time counters wrap (see adapter->ts_used_bits)
++ * - sometimes, dev_ts_1 < ts < dev_ts2
++ *
++ * "normal" case (sync time counters increase):
++ * must take into account case when ts wraps (tsw)
++ *
++ * < ts_period > < >
++ * | | |
++ * ---+--------+----+-------0-+--+-->
++ * ts_dev_1 | ts_dev_2 |
++ * ts tsw
++ */
++ if (time_ref->ts_dev_1 < time_ref->ts_dev_2) {
++ /* case when event time (tsw) wraps */
++ if (ts < time_ref->ts_dev_1)
++ delta_ts = 1 << time_ref->adapter->ts_used_bits;
++
++ /* Otherwise, sync time counter (ts_dev_2) has wrapped:
++ * handle case when event time (tsn) hasn't.
++ *
++ * < ts_period > < >
++ * | | |
++ * ---+--------+--0-+---------+--+-->
++ * ts_dev_1 | ts_dev_2 |
++ * tsn ts
++ */
++ } else if (time_ref->ts_dev_1 < ts) {
++ delta_ts = -(1 << time_ref->adapter->ts_used_bits);
++ }
+
+- delta_us = ts - time_ref->ts_dev_2;
+- if (ts < time_ref->ts_dev_2)
+- delta_us &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ /* add delay between last sync and event timestamps */
++ delta_ts += (signed int)(ts - time_ref->ts_dev_2);
+
+- delta_us += time_ref->ts_total;
++ /* add time from beginning to last sync */
++ delta_ts += time_ref->ts_total;
+
+- delta_us *= time_ref->adapter->us_per_ts_scale;
++ /* convert ticks number into microseconds */
++ delta_us = delta_ts * time_ref->adapter->us_per_ts_scale;
+ delta_us >>= time_ref->adapter->us_per_ts_shift;
+
+ *time = ktime_add_us(time_ref->tv_host_0, delta_us);
+--
+2.27.0
+
--- /dev/null
+From ed791d697e66a7fc4fa8a754d2d762c3be0faf23 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Jun 2020 12:47:06 +0200
+Subject: can: rx-offload: don't call kfree_skb() from IRQ context
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+[ Upstream commit 2ddd6bfe7bdbb6c661835c3ff9cab8e0769940a6 ]
+
+A CAN driver, using the rx-offload infrastructure, is reading CAN frames
+(usually in IRQ context) from the hardware and placing it into the rx-offload
+queue to be delivered to the networking stack via NAPI.
+
+In case the rx-offload queue is full, trying to add more skbs results in the
+skbs being dropped using kfree_skb(). If done from hard-IRQ context this
+results in the following warning:
+
+[ 682.552693] ------------[ cut here ]------------
+[ 682.557360] WARNING: CPU: 0 PID: 3057 at net/core/skbuff.c:650 skb_release_head_state+0x74/0x84
+[ 682.566075] Modules linked in: can_raw can coda_vpu flexcan dw_hdmi_ahb_audio v4l2_jpeg imx_vdoa can_dev
+[ 682.575597] CPU: 0 PID: 3057 Comm: cansend Tainted: G W 5.7.0+ #18
+[ 682.583098] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
+[ 682.589657] [<c0112628>] (unwind_backtrace) from [<c010c1c4>] (show_stack+0x10/0x14)
+[ 682.597423] [<c010c1c4>] (show_stack) from [<c06c481c>] (dump_stack+0xe0/0x114)
+[ 682.604759] [<c06c481c>] (dump_stack) from [<c0128f10>] (__warn+0xc0/0x10c)
+[ 682.611742] [<c0128f10>] (__warn) from [<c0129314>] (warn_slowpath_fmt+0x5c/0xc0)
+[ 682.619248] [<c0129314>] (warn_slowpath_fmt) from [<c0b95dec>] (skb_release_head_state+0x74/0x84)
+[ 682.628143] [<c0b95dec>] (skb_release_head_state) from [<c0b95e08>] (skb_release_all+0xc/0x24)
+[ 682.636774] [<c0b95e08>] (skb_release_all) from [<c0b95eac>] (kfree_skb+0x74/0x1c8)
+[ 682.644479] [<c0b95eac>] (kfree_skb) from [<bf001d1c>] (can_rx_offload_queue_sorted+0xe0/0xe8 [can_dev])
+[ 682.654051] [<bf001d1c>] (can_rx_offload_queue_sorted [can_dev]) from [<bf001d6c>] (can_rx_offload_get_echo_skb+0x48/0x94 [can_dev])
+[ 682.666007] [<bf001d6c>] (can_rx_offload_get_echo_skb [can_dev]) from [<bf01efe4>] (flexcan_irq+0x194/0x5dc [flexcan])
+[ 682.676734] [<bf01efe4>] (flexcan_irq [flexcan]) from [<c019c1ec>] (__handle_irq_event_percpu+0x4c/0x3ec)
+[ 682.686322] [<c019c1ec>] (__handle_irq_event_percpu) from [<c019c5b8>] (handle_irq_event_percpu+0x2c/0x88)
+[ 682.695993] [<c019c5b8>] (handle_irq_event_percpu) from [<c019c64c>] (handle_irq_event+0x38/0x5c)
+[ 682.704887] [<c019c64c>] (handle_irq_event) from [<c01a1058>] (handle_fasteoi_irq+0xc8/0x180)
+[ 682.713432] [<c01a1058>] (handle_fasteoi_irq) from [<c019b2c0>] (generic_handle_irq+0x30/0x44)
+[ 682.722063] [<c019b2c0>] (generic_handle_irq) from [<c019b8f8>] (__handle_domain_irq+0x64/0xdc)
+[ 682.730783] [<c019b8f8>] (__handle_domain_irq) from [<c06df4a4>] (gic_handle_irq+0x48/0x9c)
+[ 682.739158] [<c06df4a4>] (gic_handle_irq) from [<c0100b30>] (__irq_svc+0x70/0x98)
+[ 682.746656] Exception stack(0xe80e9dd8 to 0xe80e9e20)
+[ 682.751725] 9dc0: 00000001 e80e8000
+[ 682.759922] 9de0: e820cf80 00000000 ffffe000 00000000 eaf08fe4 00000000 600d0013 00000000
+[ 682.768117] 9e00: c1732e3c c16093a8 e820d4c0 e80e9e28 c018a57c c018b870 600d0013 ffffffff
+[ 682.776315] [<c0100b30>] (__irq_svc) from [<c018b870>] (lock_acquire+0x108/0x4e8)
+[ 682.783821] [<c018b870>] (lock_acquire) from [<c0e938e4>] (down_write+0x48/0xa8)
+[ 682.791242] [<c0e938e4>] (down_write) from [<c02818dc>] (unlink_file_vma+0x24/0x40)
+[ 682.798922] [<c02818dc>] (unlink_file_vma) from [<c027a258>] (free_pgtables+0x34/0xb8)
+[ 682.806858] [<c027a258>] (free_pgtables) from [<c02835a4>] (exit_mmap+0xe4/0x170)
+[ 682.814361] [<c02835a4>] (exit_mmap) from [<c01248e0>] (mmput+0x5c/0x110)
+[ 682.821171] [<c01248e0>] (mmput) from [<c012e910>] (do_exit+0x374/0xbe4)
+[ 682.827892] [<c012e910>] (do_exit) from [<c0130888>] (do_group_exit+0x38/0xb4)
+[ 682.835132] [<c0130888>] (do_group_exit) from [<c0130914>] (__wake_up_parent+0x0/0x14)
+[ 682.843063] irq event stamp: 1936
+[ 682.846399] hardirqs last enabled at (1935): [<c02938b0>] rmqueue+0xf4/0xc64
+[ 682.853553] hardirqs last disabled at (1936): [<c0100b20>] __irq_svc+0x60/0x98
+[ 682.860799] softirqs last enabled at (1878): [<bf04cdcc>] raw_release+0x108/0x1f0 [can_raw]
+[ 682.869256] softirqs last disabled at (1876): [<c0b8f478>] release_sock+0x18/0x98
+[ 682.876753] ---[ end trace 7bca4751ce44c444 ]---
+
+This patch fixes the problem by replacing the kfree_skb() by
+dev_kfree_skb_any(), as rx-offload might be called from threaded IRQ handlers
+as well.
+
+Fixes: ca913f1ac024 ("can: rx-offload: can_rx_offload_queue_sorted(): fix error handling, avoid skb mem leak")
+Fixes: 6caf8a6d6586 ("can: rx-offload: can_rx_offload_queue_tail(): fix error handling, avoid skb mem leak")
+Link: http://lore.kernel.org/r/20201019190524.1285319-3-mkl@pengutronix.de
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/rx-offload.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/rx-offload.c b/drivers/net/can/rx-offload.c
+index 5f7e97d54733c..5cf4171df1f42 100644
+--- a/drivers/net/can/rx-offload.c
++++ b/drivers/net/can/rx-offload.c
+@@ -281,7 +281,7 @@ int can_rx_offload_queue_sorted(struct can_rx_offload *offload,
+
+ if (skb_queue_len(&offload->skb_queue) >
+ offload->skb_queue_len_max) {
+- kfree_skb(skb);
++ dev_kfree_skb_any(skb);
+ return -ENOBUFS;
+ }
+
+@@ -326,7 +326,7 @@ int can_rx_offload_queue_tail(struct can_rx_offload *offload,
+ {
+ if (skb_queue_len(&offload->skb_queue) >
+ offload->skb_queue_len_max) {
+- kfree_skb(skb);
++ dev_kfree_skb_any(skb);
+ return -ENOBUFS;
+ }
+
+--
+2.27.0
+
--- /dev/null
+From 068f48c709ffb8927085f97929ca6b82cdb9f898 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Oct 2020 21:41:44 +0100
+Subject: genirq: Let GENERIC_IRQ_IPI select IRQ_DOMAIN_HIERARCHY
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit 151a535171be6ff824a0a3875553ea38570f4c05 ]
+
+kernel/irq/ipi.c otherwise fails to compile if nothing else
+selects it.
+
+Fixes: 379b656446a3 ("genirq: Add GENERIC_IRQ_IPI Kconfig symbol")
+Reported-by: Pavel Machek <pavel@ucw.cz>
+Tested-by: Pavel Machek <pavel@ucw.cz>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20201015101222.GA32747@amd
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/irq/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
+index 5f3e2baefca92..d532bf0c5a672 100644
+--- a/kernel/irq/Kconfig
++++ b/kernel/irq/Kconfig
+@@ -80,6 +80,7 @@ config IRQ_FASTEOI_HIERARCHY_HANDLERS
+ # Generic IRQ IPI support
+ config GENERIC_IRQ_IPI
+ bool
++ select IRQ_DOMAIN_HIERARCHY
+
+ # Generic MSI interrupt support
+ config GENERIC_MSI_IRQ
+--
+2.27.0
+
--- /dev/null
+From 6546a5b96b1f9bce697645481cee93bfb754ef71 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 8 Oct 2020 09:12:15 +0200
+Subject: hv_balloon: disable warning when floor reached
+
+From: Olaf Hering <olaf@aepfle.de>
+
+[ Upstream commit 2c3bd2a5c86fe744e8377733c5e511a5ca1e14f5 ]
+
+It is not an error if the host requests to balloon down, but the VM
+refuses to do so. Without this change a warning is logged in dmesg
+every five minutes.
+
+Fixes: b3bb97b8a49f3 ("Drivers: hv: balloon: Add logging for dynamic memory operations")
+
+Signed-off-by: Olaf Hering <olaf@aepfle.de>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/20201008071216.16554-1-olaf@aepfle.de
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/hv_balloon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
+index 9ca0706a9d402..e5fc719a34e70 100644
+--- a/drivers/hv/hv_balloon.c
++++ b/drivers/hv/hv_balloon.c
+@@ -1275,7 +1275,7 @@ static void balloon_up(struct work_struct *dummy)
+
+ /* Refuse to balloon below the floor. */
+ if (avail_pages < num_pages || avail_pages - num_pages < floor) {
+- pr_warn("Balloon request will be partially fulfilled. %s\n",
++ pr_info("Balloon request will be partially fulfilled. %s\n",
+ avail_pages < num_pages ? "Not enough memory." :
+ "Balloon floor reached.");
+
+--
+2.27.0
+
--- /dev/null
+From 337382e09a38ac79003ca41d5d7c36aaf252ad7b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Oct 2020 15:24:34 +0800
+Subject: nbd: don't update block size after device is started
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ Upstream commit b40813ddcd6bf9f01d020804e4cb8febc480b9e4 ]
+
+Mounted NBD device can be resized, one use case is rbd-nbd.
+
+Fix the issue by setting up default block size, then not touch it
+in nbd_size_update() any more. This kind of usage is aligned with loop
+which has same use case too.
+
+Cc: stable@vger.kernel.org
+Fixes: c8a83a6b54d0 ("nbd: Use set_blocksize() to set device blocksize")
+Reported-by: lining <lining2020x@163.com>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Cc: Josef Bacik <josef@toxicpanda.com>
+Cc: Jan Kara <jack@suse.cz>
+Tested-by: lining <lining2020x@163.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/nbd.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
+index 52e1e71e81241..706115ecd9bee 100644
+--- a/drivers/block/nbd.c
++++ b/drivers/block/nbd.c
+@@ -276,7 +276,7 @@ static void nbd_size_clear(struct nbd_device *nbd)
+ }
+ }
+
+-static void nbd_size_update(struct nbd_device *nbd)
++static void nbd_size_update(struct nbd_device *nbd, bool start)
+ {
+ struct nbd_config *config = nbd->config;
+ struct block_device *bdev = bdget_disk(nbd->disk, 0);
+@@ -292,7 +292,8 @@ static void nbd_size_update(struct nbd_device *nbd)
+ if (bdev) {
+ if (bdev->bd_disk) {
+ bd_set_size(bdev, config->bytesize);
+- set_blocksize(bdev, config->blksize);
++ if (start)
++ set_blocksize(bdev, config->blksize);
+ } else
+ bdev->bd_invalidated = 1;
+ bdput(bdev);
+@@ -307,7 +308,7 @@ static void nbd_size_set(struct nbd_device *nbd, loff_t blocksize,
+ config->blksize = blocksize;
+ config->bytesize = blocksize * nr_blocks;
+ if (nbd->task_recv != NULL)
+- nbd_size_update(nbd);
++ nbd_size_update(nbd, false);
+ }
+
+ static void nbd_complete_rq(struct request *req)
+@@ -1244,7 +1245,7 @@ static int nbd_start_device(struct nbd_device *nbd)
+ args->index = i;
+ queue_work(nbd->recv_workq, &args->work);
+ }
+- nbd_size_update(nbd);
++ nbd_size_update(nbd, true);
+ return error;
+ }
+
+--
+2.27.0
+
--- /dev/null
+From 7a90690515a123c280238b3e8558c43d14270e38 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Oct 2020 09:05:35 +0200
+Subject: net: xfrm: fix a race condition during allocing spi
+
+From: zhuoliang zhang <zhuoliang.zhang@mediatek.com>
+
+[ Upstream commit a779d91314ca7208b7feb3ad817b62904397c56d ]
+
+we found that the following race condition exists in
+xfrm_alloc_userspi flow:
+
+user thread state_hash_work thread
+---- ----
+xfrm_alloc_userspi()
+ __find_acq_core()
+ /*alloc new xfrm_state:x*/
+ xfrm_state_alloc()
+ /*schedule state_hash_work thread*/
+ xfrm_hash_grow_check() xfrm_hash_resize()
+ xfrm_alloc_spi /*hold lock*/
+ x->id.spi = htonl(spi) spin_lock_bh(&net->xfrm.xfrm_state_lock)
+ /*waiting lock release*/ xfrm_hash_transfer()
+ spin_lock_bh(&net->xfrm.xfrm_state_lock) /*add x into hlist:net->xfrm.state_byspi*/
+ hlist_add_head_rcu(&x->byspi)
+ spin_unlock_bh(&net->xfrm.xfrm_state_lock)
+
+ /*add x into hlist:net->xfrm.state_byspi 2 times*/
+ hlist_add_head_rcu(&x->byspi)
+
+1. a new state x is alloced in xfrm_state_alloc() and added into the bydst hlist
+in __find_acq_core() on the LHS;
+2. on the RHS, state_hash_work thread travels the old bydst and tranfers every xfrm_state
+(include x) into the new bydst hlist and new byspi hlist;
+3. user thread on the LHS gets the lock and adds x into the new byspi hlist again.
+
+So the same xfrm_state (x) is added into the same list_hash
+(net->xfrm.state_byspi) 2 times that makes the list_hash become
+an inifite loop.
+
+To fix the race, x->id.spi = htonl(spi) in the xfrm_alloc_spi() is moved
+to the back of spin_lock_bh, sothat state_hash_work thread no longer add x
+which id.spi is zero into the hash_list.
+
+Fixes: f034b5d4efdf ("[XFRM]: Dynamic xfrm_state hash table sizing.")
+Signed-off-by: zhuoliang zhang <zhuoliang.zhang@mediatek.com>
+Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xfrm/xfrm_state.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
+index a649d7c2f48ca..84dea0ad16661 100644
+--- a/net/xfrm/xfrm_state.c
++++ b/net/xfrm/xfrm_state.c
+@@ -1825,6 +1825,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high)
+ int err = -ENOENT;
+ __be32 minspi = htonl(low);
+ __be32 maxspi = htonl(high);
++ __be32 newspi = 0;
+ u32 mark = x->mark.v & x->mark.m;
+
+ spin_lock_bh(&x->lock);
+@@ -1843,21 +1844,22 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high)
+ xfrm_state_put(x0);
+ goto unlock;
+ }
+- x->id.spi = minspi;
++ newspi = minspi;
+ } else {
+ u32 spi = 0;
+ for (h = 0; h < high-low+1; h++) {
+ spi = low + prandom_u32()%(high-low+1);
+ x0 = xfrm_state_lookup(net, mark, &x->id.daddr, htonl(spi), x->id.proto, x->props.family);
+ if (x0 == NULL) {
+- x->id.spi = htonl(spi);
++ newspi = htonl(spi);
+ break;
+ }
+ xfrm_state_put(x0);
+ }
+ }
+- if (x->id.spi) {
++ if (newspi) {
+ spin_lock_bh(&net->xfrm.xfrm_state_lock);
++ x->id.spi = newspi;
+ h = xfrm_spi_hash(net, &x->id.daddr, x->id.spi, x->id.proto, x->props.family);
+ hlist_add_head_rcu(&x->byspi, net->xfrm.state_byspi + h);
+ spin_unlock_bh(&net->xfrm.xfrm_state_lock);
+--
+2.27.0
+
--- /dev/null
+From dd6671647c6016df7ac1f6174e53500cd45180d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Oct 2020 16:39:46 +0100
+Subject: netfilter: ipset: Update byte and packet counters regardless of
+ whether they match
+
+From: Stefano Brivio <sbrivio@redhat.com>
+
+[ Upstream commit 7d10e62c2ff8e084c136c94d32d9a94de4d31248 ]
+
+In ip_set_match_extensions(), for sets with counters, we take care of
+updating counters themselves by calling ip_set_update_counter(), and of
+checking if the given comparison and values match, by calling
+ip_set_match_counter() if needed.
+
+However, if a given comparison on counters doesn't match the configured
+values, that doesn't mean the set entry itself isn't matching.
+
+This fix restores the behaviour we had before commit 4750005a85f7
+("netfilter: ipset: Fix "don't update counters" mode when counters used
+at the matching"), without reintroducing the issue fixed there: back
+then, mtype_data_match() first updated counters in any case, and then
+took care of matching on counters.
+
+Now, if the IPSET_FLAG_SKIP_COUNTER_UPDATE flag is set,
+ip_set_update_counter() will anyway skip counter updates if desired.
+
+The issue observed is illustrated by this reproducer:
+
+ ipset create c hash:ip counters
+ ipset add c 192.0.2.1
+ iptables -I INPUT -m set --match-set c src --bytes-gt 800 -j DROP
+
+if we now send packets from 192.0.2.1, bytes and packets counters
+for the entry as shown by 'ipset list' are always zero, and, no
+matter how many bytes we send, the rule will never match, because
+counters themselves are not updated.
+
+Reported-by: Mithil Mhatre <mmhatre@redhat.com>
+Fixes: 4750005a85f7 ("netfilter: ipset: Fix "don't update counters" mode when counters used at the matching")
+Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
+Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipset/ip_set_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
+index 36ebc40a4313c..0427e66bc4786 100644
+--- a/net/netfilter/ipset/ip_set_core.c
++++ b/net/netfilter/ipset/ip_set_core.c
+@@ -488,13 +488,14 @@ ip_set_match_extensions(struct ip_set *set, const struct ip_set_ext *ext,
+ if (SET_WITH_COUNTER(set)) {
+ struct ip_set_counter *counter = ext_counter(data, set);
+
++ ip_set_update_counter(counter, ext, flags);
++
+ if (flags & IPSET_FLAG_MATCH_COUNTERS &&
+ !(ip_set_match_counter(ip_set_get_packets(counter),
+ mext->packets, mext->packets_op) &&
+ ip_set_match_counter(ip_set_get_bytes(counter),
+ mext->bytes, mext->bytes_op)))
+ return false;
+- ip_set_update_counter(counter, ext, flags);
+ }
+ if (SET_WITH_SKBINFO(set))
+ ip_set_get_skbinfo(ext_skbinfo(data, set),
+--
+2.27.0
+
--- /dev/null
+From 01ed5fd2b5731853f038dadf67d349475c452eed Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 2 Nov 2020 00:31:03 +0100
+Subject: perf tools: Add missing swap for ino_generation
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+[ Upstream commit fe01adb72356a4e2f8735e4128af85921ca98fa1 ]
+
+We are missing swap for ino_generation field.
+
+Fixes: 5c5e854bc760 ("perf tools: Add attr->mmap2 support")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Acked-by: Namhyung Kim <namhyung@kernel.org>
+Link: https://lore.kernel.org/r/20201101233103.3537427-2-jolsa@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/session.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
+index f016d1b330e54..6a2037b52098b 100644
+--- a/tools/perf/util/session.c
++++ b/tools/perf/util/session.c
+@@ -488,6 +488,7 @@ static void perf_event__mmap2_swap(union perf_event *event,
+ event->mmap2.maj = bswap_32(event->mmap2.maj);
+ event->mmap2.min = bswap_32(event->mmap2.min);
+ event->mmap2.ino = bswap_64(event->mmap2.ino);
++ event->mmap2.ino_generation = bswap_64(event->mmap2.ino_generation);
+
+ if (sample_id_all) {
+ void *data = &event->mmap2.filename;
+--
+2.27.0
+
--- /dev/null
+From fdd0594c99c2cff43762d3ade9f31c6bb18297e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 2 Nov 2020 22:27:27 +0100
+Subject: regulator: defer probe when trying to get voltage from unresolved
+ supply
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+
+[ Upstream commit cf1ad559a20d1930aa7b47a52f54e1f8718de301 ]
+
+regulator_get_voltage_rdev() is called in regulator probe() when
+applying machine constraints. The "fixed" commit exposed the problem
+that non-bypassed regulators can forward the request to its parent
+(like bypassed ones) supply. Return -EPROBE_DEFER when the supply
+is expected but not resolved yet.
+
+Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
+Cc: stable@vger.kernel.org
+Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+Reported-by: Ondřej Jirman <megous@megous.com>
+Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
+Tested-by: Ondřej Jirman <megous@megous.com>
+Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/regulator/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index c290c89421314..ad5235ca8e4ee 100644
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -3405,6 +3405,8 @@ static int _regulator_get_voltage(struct regulator_dev *rdev)
+ ret = rdev->desc->fixed_uV;
+ } else if (rdev->supply) {
+ ret = _regulator_get_voltage(rdev->supply->rdev);
++ } else if (rdev->supply_name) {
++ return -EPROBE_DEFER;
+ } else {
+ return -EINVAL;
+ }
+--
+2.27.0
+
--- /dev/null
+regulator-defer-probe-when-trying-to-get-voltage-fro.patch
+time-prevent-undefined-behaviour-in-timespec64_to_ns.patch
+nbd-don-t-update-block-size-after-device-is-started.patch
+usb-dwc3-gadget-continue-to-process-pending-requests.patch
+usb-dwc3-gadget-reclaim-extra-trbs-after-request-com.patch
+btrfs-sysfs-init-devices-outside-of-the-chunk_mutex.patch
+btrfs-reschedule-when-cloning-lots-of-extents.patch
+genirq-let-generic_irq_ipi-select-irq_domain_hierarc.patch
+hv_balloon-disable-warning-when-floor-reached.patch
+net-xfrm-fix-a-race-condition-during-allocing-spi.patch
+xfs-set-xefi_discard-when-creating-a-deferred-agfl-f.patch
+netfilter-ipset-update-byte-and-packet-counters-rega.patch
+perf-tools-add-missing-swap-for-ino_generation.patch
+alsa-hda-prevent-undefined-shift-in-snd_hdac_ext_bus.patch
+can-rx-offload-don-t-call-kfree_skb-from-irq-context.patch
+can-dev-can_get_echo_skb-prevent-call-to-kfree_skb-i.patch
+can-dev-__can_get_echo_skb-fix-real-payload-length-r.patch
+can-can_create_echo_skb-fix-echo-skb-generation-alwa.patch
+can-peak_usb-add-range-checking-in-decode-operations.patch
+can-peak_usb-peak_usb_get_ts_time-fix-timestamp-wrap.patch
+can-peak_canfd-pucan_handle_can_rx-fix-echo-manageme.patch
+can-flexcan-remove-flexcan_quirk_disable_mecr-quirk-.patch
+xfs-flush-new-eof-page-on-truncate-to-avoid-post-eof.patch
+xfs-fix-scrub-flagging-rtinherit-even-if-there-is-no.patch
+tpm-efi-don-t-create-binary_bios_measurements-file-f.patch
--- /dev/null
+From c5021b2547ad5b6ca573c6675d78c0930f32eb9e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Sep 2020 17:30:13 +0800
+Subject: time: Prevent undefined behaviour in timespec64_to_ns()
+
+From: Zeng Tao <prime.zeng@hisilicon.com>
+
+[ Upstream commit cb47755725da7b90fecbb2aa82ac3b24a7adb89b ]
+
+UBSAN reports:
+
+Undefined behaviour in ./include/linux/time64.h:127:27
+signed integer overflow:
+17179869187 * 1000000000 cannot be represented in type 'long long int'
+Call Trace:
+ timespec64_to_ns include/linux/time64.h:127 [inline]
+ set_cpu_itimer+0x65c/0x880 kernel/time/itimer.c:180
+ do_setitimer+0x8e/0x740 kernel/time/itimer.c:245
+ __x64_sys_setitimer+0x14c/0x2c0 kernel/time/itimer.c:336
+ do_syscall_64+0xa1/0x540 arch/x86/entry/common.c:295
+
+Commit bd40a175769d ("y2038: itimer: change implementation to timespec64")
+replaced the original conversion which handled time clamping correctly with
+timespec64_to_ns() which has no overflow protection.
+
+Fix it in timespec64_to_ns() as this is not necessarily limited to the
+usage in itimers.
+
+[ tglx: Added comment and adjusted the fixes tag ]
+
+Fixes: 361a3bf00582 ("time64: Add time64.h header and define struct timespec64")
+Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/1598952616-6416-1-git-send-email-prime.zeng@hisilicon.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/time64.h | 4 ++++
+ kernel/time/itimer.c | 4 ----
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/include/linux/time64.h b/include/linux/time64.h
+index 4a45aea0f96e9..8dbdf6cae3e8b 100644
+--- a/include/linux/time64.h
++++ b/include/linux/time64.h
+@@ -138,6 +138,10 @@ static inline bool timespec64_valid_settod(const struct timespec64 *ts)
+ */
+ static inline s64 timespec64_to_ns(const struct timespec64 *ts)
+ {
++ /* Prevent multiplication overflow */
++ if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
++ return KTIME_MAX;
++
+ return ((s64) ts->tv_sec * NSEC_PER_SEC) + ts->tv_nsec;
+ }
+
+diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c
+index 9a65713c83093..2e2b335ef1018 100644
+--- a/kernel/time/itimer.c
++++ b/kernel/time/itimer.c
+@@ -154,10 +154,6 @@ static void set_cpu_itimer(struct task_struct *tsk, unsigned int clock_id,
+ u64 oval, nval, ointerval, ninterval;
+ struct cpu_itimer *it = &tsk->signal->it[clock_id];
+
+- /*
+- * Use the to_ktime conversion because that clamps the maximum
+- * value to KTIME_MAX and avoid multiplication overflows.
+- */
+ nval = ktime_to_ns(timeval_to_ktime(value->it_value));
+ ninterval = ktime_to_ns(timeval_to_ktime(value->it_interval));
+
+--
+2.27.0
+
--- /dev/null
+From 015be5fd62018ad6039078e3349a82df28808a57 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Oct 2020 10:41:02 -0500
+Subject: tpm: efi: Don't create binary_bios_measurements file for an empty log
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tyler Hicks <tyhicks@linux.microsoft.com>
+
+[ Upstream commit 8ffd778aff45be760292225049e0141255d4ad6e ]
+
+Mimic the pre-existing ACPI and Device Tree event log behavior by not
+creating the binary_bios_measurements file when the EFI TPM event log is
+empty.
+
+This fixes the following NULL pointer dereference that can occur when
+reading /sys/kernel/security/tpm0/binary_bios_measurements after the
+kernel received an empty event log from the firmware:
+
+ BUG: kernel NULL pointer dereference, address: 000000000000002c
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: 0000 [#1] SMP PTI
+ CPU: 2 PID: 3932 Comm: fwupdtpmevlog Not tainted 5.9.0-00003-g629990edad62 #17
+ Hardware name: LENOVO 20LCS03L00/20LCS03L00, BIOS N27ET38W (1.24 ) 11/28/2019
+ RIP: 0010:tpm2_bios_measurements_start+0x3a/0x550
+ Code: 54 53 48 83 ec 68 48 8b 57 70 48 8b 1e 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 82 c0 06 00 00 48 8b 8a c8 06 00 00 <44> 8b 60 1c 48 89 4d a0 4c 89 e2 49 83 c4 20 48 83 fb 00 75 2a 49
+ RSP: 0018:ffffa9c901203db0 EFLAGS: 00010246
+ RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010
+ RDX: ffff8ba1eb99c000 RSI: ffff8ba1e4ce8280 RDI: ffff8ba1e4ce8258
+ RBP: ffffa9c901203e40 R08: ffffa9c901203dd8 R09: ffff8ba1ec443300
+ R10: ffffa9c901203e50 R11: 0000000000000000 R12: ffff8ba1e4ce8280
+ R13: ffffa9c901203ef0 R14: ffffa9c901203ef0 R15: ffff8ba1e4ce8258
+ FS: 00007f6595460880(0000) GS:ffff8ba1ef880000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 000000000000002c CR3: 00000007d8d18003 CR4: 00000000003706e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ ? __kmalloc_node+0x113/0x320
+ ? kvmalloc_node+0x31/0x80
+ seq_read+0x94/0x420
+ vfs_read+0xa7/0x190
+ ksys_read+0xa7/0xe0
+ __x64_sys_read+0x1a/0x20
+ do_syscall_64+0x37/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+In this situation, the bios_event_log pointer in the tpm_bios_log struct
+was not NULL but was equal to the ZERO_SIZE_PTR (0x10) value. This was
+due to the following kmemdup() in tpm_read_log_efi():
+
+int tpm_read_log_efi(struct tpm_chip *chip)
+{
+...
+ /* malloc EventLog space */
+ log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL);
+ if (!log->bios_event_log) {
+ ret = -ENOMEM;
+ goto out;
+ }
+...
+}
+
+When log_size is zero, due to an empty event log from firmware,
+ZERO_SIZE_PTR is returned from kmemdup(). Upon a read of the
+binary_bios_measurements file, the tpm2_bios_measurements_start()
+function does not perform a ZERO_OR_NULL_PTR() check on the
+bios_event_log pointer before dereferencing it.
+
+Rather than add a ZERO_OR_NULL_PTR() check in functions that make use of
+the bios_event_log pointer, simply avoid creating the
+binary_bios_measurements_file as is done in other event log retrieval
+backends.
+
+Explicitly ignore all of the events in the final event log when the main
+event log is empty. The list of events in the final event log cannot be
+accurately parsed without referring to the first event in the main event
+log (the event log header) so the final event log is useless in such a
+situation.
+
+Fixes: 58cc1e4faf10 ("tpm: parse TPM event logs based on EFI table")
+Link: https://lore.kernel.org/linux-integrity/E1FDCCCB-CA51-4AEE-AC83-9CDE995EAE52@canonical.com/
+Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Reported-by: Kenneth R. Crudup <kenny@panix.com>
+Reported-by: Mimi Zohar <zohar@linux.ibm.com>
+Cc: Thiébaud Weksteen <tweek@google.com>
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/char/tpm/eventlog/efi.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/char/tpm/eventlog/efi.c b/drivers/char/tpm/eventlog/efi.c
+index 3e673ab22cb45..abd3beeb51589 100644
+--- a/drivers/char/tpm/eventlog/efi.c
++++ b/drivers/char/tpm/eventlog/efi.c
+@@ -43,6 +43,11 @@ int tpm_read_log_efi(struct tpm_chip *chip)
+ log_size = log_tbl->size;
+ memunmap(log_tbl);
+
++ if (!log_size) {
++ pr_warn("UEFI TPM log area empty\n");
++ return -EIO;
++ }
++
+ log_tbl = memremap(efi.tpm_log, sizeof(*log_tbl) + log_size,
+ MEMREMAP_WB);
+ if (!log_tbl) {
+--
+2.27.0
+
--- /dev/null
+From 7c6204f43e20e0018b8186fbff1a1350ed5bde4a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 31 Mar 2020 01:40:42 -0700
+Subject: usb: dwc3: gadget: Continue to process pending requests
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+[ Upstream commit d9feef974e0d8cb6842533c92476a1b32a41ba31 ]
+
+If there are still pending requests because no TRB was available,
+prepare more when started requests are completed.
+
+Introduce dwc3_gadget_ep_should_continue() to check for incomplete and
+pending requests to resume updating new TRBs to the controller's TRB
+cache.
+
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/gadget.c | 24 +++++++++++++++++++++---
+ 1 file changed, 21 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
+index f0d2f0a4e9908..f24cfb3a6907b 100644
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -2403,10 +2403,8 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
+
+ req->request.actual = req->request.length - req->remaining;
+
+- if (!dwc3_gadget_ep_request_completed(req)) {
+- __dwc3_gadget_kick_transfer(dep);
++ if (!dwc3_gadget_ep_request_completed(req))
+ goto out;
+- }
+
+ dwc3_gadget_giveback(dep, req, status);
+
+@@ -2430,6 +2428,24 @@ static void dwc3_gadget_ep_cleanup_completed_requests(struct dwc3_ep *dep,
+ }
+ }
+
++static bool dwc3_gadget_ep_should_continue(struct dwc3_ep *dep)
++{
++ struct dwc3_request *req;
++
++ if (!list_empty(&dep->pending_list))
++ return true;
++
++ /*
++ * We only need to check the first entry of the started list. We can
++ * assume the completed requests are removed from the started list.
++ */
++ req = next_request(&dep->started_list);
++ if (!req)
++ return false;
++
++ return !dwc3_gadget_ep_request_completed(req);
++}
++
+ static void dwc3_gadget_endpoint_frame_from_event(struct dwc3_ep *dep,
+ const struct dwc3_event_depevt *event)
+ {
+@@ -2459,6 +2475,8 @@ static void dwc3_gadget_endpoint_transfer_in_progress(struct dwc3_ep *dep,
+
+ if (stop)
+ dwc3_stop_active_transfer(dep, true, true);
++ else if (dwc3_gadget_ep_should_continue(dep))
++ __dwc3_gadget_kick_transfer(dep);
+
+ /*
+ * WORKAROUND: This is the 2nd half of U1/U2 -> U0 workaround.
+--
+2.27.0
+
--- /dev/null
+From 12c4654fc2a90b57274113dfa075ad2f7326428b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 24 Sep 2020 01:21:24 -0700
+Subject: usb: dwc3: gadget: Reclaim extra TRBs after request completion
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+[ Upstream commit 690e5c2dc29f8891fcfd30da67e0d5837c2c9df5 ]
+
+An SG request may be partially completed (due to no available TRBs).
+Don't reclaim extra TRBs and clear the needs_extra_trb flag until the
+request is fully completed. Otherwise, the driver will reclaim the wrong
+TRB.
+
+Cc: stable@vger.kernel.org
+Fixes: 1f512119a08c ("usb: dwc3: gadget: add remaining sg entries to ring")
+Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/gadget.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
+index f24cfb3a6907b..6ab5c48f5d873 100644
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -2386,6 +2386,11 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
+ ret = dwc3_gadget_ep_reclaim_trb_linear(dep, req, event,
+ status);
+
++ req->request.actual = req->request.length - req->remaining;
++
++ if (!dwc3_gadget_ep_request_completed(req))
++ goto out;
++
+ if (req->needs_extra_trb) {
+ unsigned int maxp = usb_endpoint_maxp(dep->endpoint.desc);
+
+@@ -2401,11 +2406,6 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
+ req->needs_extra_trb = false;
+ }
+
+- req->request.actual = req->request.length - req->remaining;
+-
+- if (!dwc3_gadget_ep_request_completed(req))
+- goto out;
+-
+ dwc3_gadget_giveback(dep, req, status);
+
+ out:
+--
+2.27.0
+
--- /dev/null
+From f14146345d00e69e3be2060e4c6bce836ea15875 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 2 Nov 2020 17:14:07 -0800
+Subject: xfs: fix scrub flagging rtinherit even if there is no rt device
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+[ Upstream commit c1f6b1ac00756a7108e5fcb849a2f8230c0b62a5 ]
+
+The kernel has always allowed directories to have the rtinherit flag
+set, even if there is no rt device, so this check is wrong.
+
+Fixes: 80e4e1268802 ("xfs: scrub inodes")
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/xfs/scrub/inode.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/fs/xfs/scrub/inode.c b/fs/xfs/scrub/inode.c
+index e386c9b0b4ab7..8d45d60832db9 100644
+--- a/fs/xfs/scrub/inode.c
++++ b/fs/xfs/scrub/inode.c
+@@ -131,8 +131,7 @@ xchk_inode_flags(
+ goto bad;
+
+ /* rt flags require rt device */
+- if ((flags & (XFS_DIFLAG_REALTIME | XFS_DIFLAG_RTINHERIT)) &&
+- !mp->m_rtdev_targp)
++ if ((flags & XFS_DIFLAG_REALTIME) && !mp->m_rtdev_targp)
+ goto bad;
+
+ /* new rt bitmap flag only valid for rbmino */
+--
+2.27.0
+
--- /dev/null
+From a19a70a73c7a94e78709d3e5b0d1e075528f1955 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Oct 2020 14:30:48 -0700
+Subject: xfs: flush new eof page on truncate to avoid post-eof corruption
+
+From: Brian Foster <bfoster@redhat.com>
+
+[ Upstream commit 869ae85dae64b5540e4362d7fe4cd520e10ec05c ]
+
+It is possible to expose non-zeroed post-EOF data in XFS if the new
+EOF page is dirty, backed by an unwritten block and the truncate
+happens to race with writeback. iomap_truncate_page() will not zero
+the post-EOF portion of the page if the underlying block is
+unwritten. The subsequent call to truncate_setsize() will, but
+doesn't dirty the page. Therefore, if writeback happens to complete
+after iomap_truncate_page() (so it still sees the unwritten block)
+but before truncate_setsize(), the cached page becomes inconsistent
+with the on-disk block. A mapped read after the associated page is
+reclaimed or invalidated exposes non-zero post-EOF data.
+
+For example, consider the following sequence when run on a kernel
+modified to explicitly flush the new EOF page within the race
+window:
+
+$ xfs_io -fc "falloc 0 4k" -c fsync /mnt/file
+$ xfs_io -c "pwrite 0 4k" -c "truncate 1k" /mnt/file
+ ...
+$ xfs_io -c "mmap 0 4k" -c "mread -v 1k 8" /mnt/file
+00000400: 00 00 00 00 00 00 00 00 ........
+$ umount /mnt/; mount <dev> /mnt/
+$ xfs_io -c "mmap 0 4k" -c "mread -v 1k 8" /mnt/file
+00000400: cd cd cd cd cd cd cd cd ........
+
+Update xfs_setattr_size() to explicitly flush the new EOF page prior
+to the page truncate to ensure iomap has the latest state of the
+underlying block.
+
+Fixes: 68a9f5e7007c ("xfs: implement iomap based buffered write path")
+Signed-off-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/xfs/xfs_iops.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
+index e427ad097e2ee..948ac1290121b 100644
+--- a/fs/xfs/xfs_iops.c
++++ b/fs/xfs/xfs_iops.c
+@@ -895,6 +895,16 @@ xfs_setattr_size(
+ error = iomap_zero_range(inode, oldsize, newsize - oldsize,
+ &did_zeroing, &xfs_iomap_ops);
+ } else {
++ /*
++ * iomap won't detect a dirty page over an unwritten block (or a
++ * cow block over a hole) and subsequently skips zeroing the
++ * newly post-EOF portion of the page. Flush the new EOF to
++ * convert the block before the pagecache truncate.
++ */
++ error = filemap_write_and_wait_range(inode->i_mapping, newsize,
++ newsize);
++ if (error)
++ return error;
+ error = iomap_truncate_page(inode, newsize, &did_zeroing,
+ &xfs_iomap_ops);
+ }
+--
+2.27.0
+
--- /dev/null
+From 83f6f6142407850fcb48ad9b05260cb6196fd288 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Oct 2020 15:19:38 -0700
+Subject: xfs: set xefi_discard when creating a deferred agfl free log intent
+ item
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+[ Upstream commit 2c334e12f957cd8c6bb66b4aa3f79848b7c33cab ]
+
+Make sure that we actually initialize xefi_discard when we're scheduling
+a deferred free of an AGFL block. This was (eventually) found by the
+UBSAN while I was banging on realtime rmap problems, but it exists in
+the upstream codebase. While we're at it, rearrange the structure to
+reduce the struct size from 64 to 56 bytes.
+
+Fixes: fcb762f5de2e ("xfs: add bmapi nodiscard flag")
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/xfs/libxfs/xfs_alloc.c | 1 +
+ fs/xfs/libxfs/xfs_bmap.h | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
+index 1eb7933dac83e..b3a9043b0c9ee 100644
+--- a/fs/xfs/libxfs/xfs_alloc.c
++++ b/fs/xfs/libxfs/xfs_alloc.c
+@@ -2213,6 +2213,7 @@ xfs_defer_agfl_block(
+ new->xefi_startblock = XFS_AGB_TO_FSB(mp, agno, agbno);
+ new->xefi_blockcount = 1;
+ new->xefi_oinfo = *oinfo;
++ new->xefi_skip_discard = false;
+
+ trace_xfs_agfl_free_defer(mp, agno, 0, agbno, 1);
+
+diff --git a/fs/xfs/libxfs/xfs_bmap.h b/fs/xfs/libxfs/xfs_bmap.h
+index 488dc8860fd7c..50242ba3cdb72 100644
+--- a/fs/xfs/libxfs/xfs_bmap.h
++++ b/fs/xfs/libxfs/xfs_bmap.h
+@@ -52,9 +52,9 @@ struct xfs_extent_free_item
+ {
+ xfs_fsblock_t xefi_startblock;/* starting fs block number */
+ xfs_extlen_t xefi_blockcount;/* number of blocks in extent */
++ bool xefi_skip_discard;
+ struct list_head xefi_list;
+ struct xfs_owner_info xefi_oinfo; /* extent owner */
+- bool xefi_skip_discard;
+ };
+
+ #define XFS_BMAP_MAX_NMAP 4
+--
+2.27.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
