--- /dev/null
+From 5368512abe08a28525d9b24abbfc2a72493e8dba Mon Sep 17 00:00:00 2001
+From: Wei Huang <wei.huang2@amd.com>
+Date: Sun, 18 Oct 2020 22:57:41 -0500
+Subject: acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
+
+From: Wei Huang <wei.huang2@amd.com>
+
+commit 5368512abe08a28525d9b24abbfc2a72493e8dba upstream.
+
+acpi-cpufreq has a old quirk that overrides the _PSD table supplied by
+BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+)
+now accurately reports the P-state dependency of CPU cores. Hence this
+quirk needs to be fixed in order to support new CPUs' frequency control.
+
+Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs")
+Signed-off-by: Wei Huang <wei.huang2@amd.com>
+[ rjw: Subject edit ]
+Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/acpi-cpufreq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/cpufreq/acpi-cpufreq.c
++++ b/drivers/cpufreq/acpi-cpufreq.c
+@@ -701,7 +701,8 @@ static int acpi_cpufreq_cpu_init(struct
+ cpumask_copy(policy->cpus, topology_core_cpumask(cpu));
+ }
+
+- if (check_amd_hwpstate_cpu(cpu) && !acpi_pstate_strict) {
++ if (check_amd_hwpstate_cpu(cpu) && boot_cpu_data.x86 < 0x19 &&
++ !acpi_pstate_strict) {
+ cpumask_clear(policy->cpus);
+ cpumask_set_cpu(cpu, policy->cpus);
+ cpumask_copy(data->freqdomain_cpus,
--- /dev/null
+From 0fada277147ffc6d694aa32162f51198d4f10d94 Mon Sep 17 00:00:00 2001
+From: Jamie Iles <jamie@nuviainc.com>
+Date: Mon, 12 Oct 2020 14:04:46 +0100
+Subject: ACPI: debug: don't allow debugging when ACPI is disabled
+
+From: Jamie Iles <jamie@nuviainc.com>
+
+commit 0fada277147ffc6d694aa32162f51198d4f10d94 upstream.
+
+If ACPI is disabled then loading the acpi_dbg module will result in the
+following splat when lock debugging is enabled.
+
+ DEBUG_LOCKS_WARN_ON(lock->magic != lock)
+ WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:938 __mutex_lock+0xa10/0x1290
+ Kernel panic - not syncing: panic_on_warn set ...
+ CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8+ #103
+ Hardware name: linux,dummy-virt (DT)
+ Call trace:
+ dump_backtrace+0x0/0x4d8
+ show_stack+0x34/0x48
+ dump_stack+0x174/0x1f8
+ panic+0x360/0x7a0
+ __warn+0x244/0x2ec
+ report_bug+0x240/0x398
+ bug_handler+0x50/0xc0
+ call_break_hook+0x160/0x1d8
+ brk_handler+0x30/0xc0
+ do_debug_exception+0x184/0x340
+ el1_dbg+0x48/0xb0
+ el1_sync_handler+0x170/0x1c8
+ el1_sync+0x80/0x100
+ __mutex_lock+0xa10/0x1290
+ mutex_lock_nested+0x6c/0xc0
+ acpi_register_debugger+0x40/0x88
+ acpi_aml_init+0xc4/0x114
+ do_one_initcall+0x24c/0xb10
+ kernel_init_freeable+0x690/0x728
+ kernel_init+0x20/0x1e8
+ ret_from_fork+0x10/0x18
+
+This is because acpi_debugger.lock has not been initialized as
+acpi_debugger_init() is not called when ACPI is disabled. Fail module
+loading to avoid this and any subsequent problems that might arise by
+trying to debug AML when ACPI is disabled.
+
+Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities")
+Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
+Signed-off-by: Jamie Iles <jamie@nuviainc.com>
+Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpi_dbg.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/acpi/acpi_dbg.c
++++ b/drivers/acpi/acpi_dbg.c
+@@ -757,6 +757,9 @@ int __init acpi_aml_init(void)
+ goto err_exit;
+ }
+
++ if (acpi_disabled)
++ return -ENODEV;
++
+ /* Initialize AML IO interface */
+ mutex_init(&acpi_aml_io.lock);
+ init_waitqueue_head(&acpi_aml_io.wait);
--- /dev/null
+From 7cecb47f55e00282f972a1e0b09136c8cd938221 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 27 Sep 2020 22:50:42 +0100
+Subject: ACPI / extlog: Check for RDMSR failure
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+commit 7cecb47f55e00282f972a1e0b09136c8cd938221 upstream.
+
+extlog_init() uses rdmsrl() to read an MSR, which on older CPUs
+provokes a error message at boot:
+
+ unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 (native_read_msr+0x7/0x40)
+
+Use rdmsrl_safe() instead, and return -ENODEV if it fails.
+
+Reported-by: jim@photojim.ca
+References: https://bugs.debian.org/971058
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpi_extlog.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/acpi/acpi_extlog.c
++++ b/drivers/acpi/acpi_extlog.c
+@@ -224,9 +224,9 @@ static int __init extlog_init(void)
+ u64 cap;
+ int rc;
+
+- rdmsrl(MSR_IA32_MCG_CAP, cap);
+-
+- if (!(cap & MCG_ELOG_P) || !extlog_get_l1addr())
++ if (rdmsrl_safe(MSR_IA32_MCG_CAP, &cap) ||
++ !(cap & MCG_ELOG_P) ||
++ !extlog_get_l1addr())
+ return -ENODEV;
+
+ if (edac_get_report_status() == EDAC_REPORTING_FORCE) {
--- /dev/null
+From b226faab4e7890bbbccdf794e8b94276414f9058 Mon Sep 17 00:00:00 2001
+From: Alex Hung <alex.hung@canonical.com>
+Date: Sun, 13 Sep 2020 16:34:03 -0600
+Subject: ACPI: video: use ACPI backlight for HP 635 Notebook
+
+From: Alex Hung <alex.hung@canonical.com>
+
+commit b226faab4e7890bbbccdf794e8b94276414f9058 upstream.
+
+The default backlight interface is AMD's radeon_bl0 which does not
+work on this system, so use the ACPI backlight interface on it
+instead.
+
+BugLink: https://bugs.launchpad.net/bugs/1894667
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Alex Hung <alex.hung@canonical.com>
+[ rjw: Changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/video_detect.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -274,6 +274,15 @@ static const struct dmi_system_id video_
+ DMI_MATCH(DMI_PRODUCT_NAME, "530U4E/540U4E"),
+ },
+ },
++ /* https://bugs.launchpad.net/bugs/1894667 */
++ {
++ .callback = video_detect_force_video,
++ .ident = "HP 635 Notebook",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "HP 635 Notebook PC"),
++ },
++ },
+
+ /* Non win8 machines which need native backlight nevertheless */
+ {
--- /dev/null
+From 572c83acdcdafeb04e70aa46be1fa539310be20c Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Tue, 29 Sep 2020 08:53:54 -0400
+Subject: btrfs: cleanup cow block on error
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 572c83acdcdafeb04e70aa46be1fa539310be20c upstream.
+
+In fstest btrfs/064 a transaction abort in __btrfs_cow_block could lead
+to a system lockup. It gets stuck trying to write back inodes, and the
+write back thread was trying to lock an extent buffer:
+
+ $ cat /proc/2143497/stack
+ [<0>] __btrfs_tree_lock+0x108/0x250
+ [<0>] lock_extent_buffer_for_io+0x35e/0x3a0
+ [<0>] btree_write_cache_pages+0x15a/0x3b0
+ [<0>] do_writepages+0x28/0xb0
+ [<0>] __writeback_single_inode+0x54/0x5c0
+ [<0>] writeback_sb_inodes+0x1e8/0x510
+ [<0>] wb_writeback+0xcc/0x440
+ [<0>] wb_workfn+0xd7/0x650
+ [<0>] process_one_work+0x236/0x560
+ [<0>] worker_thread+0x55/0x3c0
+ [<0>] kthread+0x13a/0x150
+ [<0>] ret_from_fork+0x1f/0x30
+
+This is because we got an error while COWing a block, specifically here
+
+ if (test_bit(BTRFS_ROOT_SHAREABLE, &root->state)) {
+ ret = btrfs_reloc_cow_block(trans, root, buf, cow);
+ if (ret) {
+ btrfs_abort_transaction(trans, ret);
+ return ret;
+ }
+ }
+
+ [16402.241552] BTRFS: Transaction aborted (error -2)
+ [16402.242362] WARNING: CPU: 1 PID: 2563188 at fs/btrfs/ctree.c:1074 __btrfs_cow_block+0x376/0x540
+ [16402.249469] CPU: 1 PID: 2563188 Comm: fsstress Not tainted 5.9.0-rc6+ #8
+ [16402.249936] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
+ [16402.250525] RIP: 0010:__btrfs_cow_block+0x376/0x540
+ [16402.252417] RSP: 0018:ffff9cca40e578b0 EFLAGS: 00010282
+ [16402.252787] RAX: 0000000000000025 RBX: 0000000000000002 RCX: ffff9132bbd19388
+ [16402.253278] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9132bbd19380
+ [16402.254063] RBP: ffff9132b41a49c0 R08: 0000000000000000 R09: 0000000000000000
+ [16402.254887] R10: 0000000000000000 R11: ffff91324758b080 R12: ffff91326ef17ce0
+ [16402.255694] R13: ffff91325fc0f000 R14: ffff91326ef176b0 R15: ffff9132815e2000
+ [16402.256321] FS: 00007f542c6d7b80(0000) GS:ffff9132bbd00000(0000) knlGS:0000000000000000
+ [16402.256973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ [16402.257374] CR2: 00007f127b83f250 CR3: 0000000133480002 CR4: 0000000000370ee0
+ [16402.257867] Call Trace:
+ [16402.258072] btrfs_cow_block+0x109/0x230
+ [16402.258356] btrfs_search_slot+0x530/0x9d0
+ [16402.258655] btrfs_lookup_file_extent+0x37/0x40
+ [16402.259155] __btrfs_drop_extents+0x13c/0xd60
+ [16402.259628] ? btrfs_block_rsv_migrate+0x4f/0xb0
+ [16402.259949] btrfs_replace_file_extents+0x190/0x820
+ [16402.260873] btrfs_clone+0x9ae/0xc00
+ [16402.261139] btrfs_extent_same_range+0x66/0x90
+ [16402.261771] btrfs_remap_file_range+0x353/0x3b1
+ [16402.262333] vfs_dedupe_file_range_one.part.0+0xd5/0x140
+ [16402.262821] vfs_dedupe_file_range+0x189/0x220
+ [16402.263150] do_vfs_ioctl+0x552/0x700
+ [16402.263662] __x64_sys_ioctl+0x62/0xb0
+ [16402.264023] do_syscall_64+0x33/0x40
+ [16402.264364] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ [16402.264862] RIP: 0033:0x7f542c7d15cb
+ [16402.266901] RSP: 002b:00007ffd35944ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+ [16402.267627] RAX: ffffffffffffffda RBX: 00000000009d1968 RCX: 00007f542c7d15cb
+ [16402.268298] RDX: 00000000009d2490 RSI: 00000000c0189436 RDI: 0000000000000003
+ [16402.268958] RBP: 00000000009d2520 R08: 0000000000000036 R09: 00000000009d2e64
+ [16402.269726] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
+ [16402.270659] R13: 000000000001f000 R14: 00000000009d1970 R15: 00000000009d2e80
+ [16402.271498] irq event stamp: 0
+ [16402.271846] hardirqs last enabled at (0): [<0000000000000000>] 0x0
+ [16402.272497] hardirqs last disabled at (0): [<ffffffff910dbf59>] copy_process+0x6b9/0x1ba0
+ [16402.273343] softirqs last enabled at (0): [<ffffffff910dbf59>] copy_process+0x6b9/0x1ba0
+ [16402.273905] softirqs last disabled at (0): [<0000000000000000>] 0x0
+ [16402.274338] ---[ end trace 737874a5a41a8236 ]---
+ [16402.274669] BTRFS: error (device dm-9) in __btrfs_cow_block:1074: errno=-2 No such entry
+ [16402.276179] BTRFS info (device dm-9): forced readonly
+ [16402.277046] BTRFS: error (device dm-9) in btrfs_replace_file_extents:2723: errno=-2 No such entry
+ [16402.278744] BTRFS: error (device dm-9) in __btrfs_cow_block:1074: errno=-2 No such entry
+ [16402.279968] BTRFS: error (device dm-9) in __btrfs_cow_block:1074: errno=-2 No such entry
+ [16402.280582] BTRFS info (device dm-9): balance: ended with status: -30
+
+The problem here is that as soon as we allocate the new block it is
+locked and marked dirty in the btree inode. This means that we could
+attempt to writeback this block and need to lock the extent buffer.
+However we're not unlocking it here and thus we deadlock.
+
+Fix this by unlocking the cow block if we have any errors inside of
+__btrfs_cow_block, and also free it so we do not leak it.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Filipe Manana <fdmanana@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ctree.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/fs/btrfs/ctree.c
++++ b/fs/btrfs/ctree.c
+@@ -1130,6 +1130,8 @@ static noinline int __btrfs_cow_block(st
+
+ ret = update_ref_for_cow(trans, root, buf, cow, &last_ref);
+ if (ret) {
++ btrfs_tree_unlock(cow);
++ free_extent_buffer(cow);
+ btrfs_abort_transaction(trans, ret);
+ return ret;
+ }
+@@ -1137,6 +1139,8 @@ static noinline int __btrfs_cow_block(st
+ if (test_bit(BTRFS_ROOT_REF_COWS, &root->state)) {
+ ret = btrfs_reloc_cow_block(trans, root, buf, cow);
+ if (ret) {
++ btrfs_tree_unlock(cow);
++ free_extent_buffer(cow);
+ btrfs_abort_transaction(trans, ret);
+ return ret;
+ }
+@@ -1168,6 +1172,8 @@ static noinline int __btrfs_cow_block(st
+ if (last_ref) {
+ ret = tree_mod_log_free_eb(fs_info, buf);
+ if (ret) {
++ btrfs_tree_unlock(cow);
++ free_extent_buffer(cow);
+ btrfs_abort_transaction(trans, ret);
+ return ret;
+ }
--- /dev/null
+From 83bc1560e02e25c6439341352024ebe8488f4fbd Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 12 Oct 2020 11:55:23 +0100
+Subject: btrfs: fix use-after-free on readahead extent after failure to create it
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 83bc1560e02e25c6439341352024ebe8488f4fbd upstream.
+
+If we fail to find suitable zones for a new readahead extent, we end up
+leaving a stale pointer in the global readahead extents radix tree
+(fs_info->reada_tree), which can trigger the following trace later on:
+
+ [13367.696354] BUG: kernel NULL pointer dereference, address: 00000000000000b0
+ [13367.696802] #PF: supervisor read access in kernel mode
+ [13367.697249] #PF: error_code(0x0000) - not-present page
+ [13367.697721] PGD 0 P4D 0
+ [13367.698171] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
+ [13367.698632] CPU: 6 PID: 851214 Comm: btrfs Tainted: G W 5.9.0-rc6-btrfs-next-69 #1
+ [13367.699100] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
+ [13367.700069] RIP: 0010:__lock_acquire+0x20a/0x3970
+ [13367.700562] Code: ff 1f 0f b7 c0 48 0f (...)
+ [13367.701609] RSP: 0018:ffffb14448f57790 EFLAGS: 00010046
+ [13367.702140] RAX: 0000000000000000 RBX: 29b935140c15e8cf RCX: 0000000000000000
+ [13367.702698] RDX: 0000000000000002 RSI: ffffffffb3d66bd0 RDI: 0000000000000046
+ [13367.703240] RBP: ffff8a52ba8ac040 R08: 00000c2866ad9288 R09: 0000000000000001
+ [13367.703783] R10: 0000000000000001 R11: 00000000b66d9b53 R12: ffff8a52ba8ac9b0
+ [13367.704330] R13: 0000000000000000 R14: ffff8a532b6333e8 R15: 0000000000000000
+ [13367.704880] FS: 00007fe1df6b5700(0000) GS:ffff8a5376600000(0000) knlGS:0000000000000000
+ [13367.705438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ [13367.705995] CR2: 00000000000000b0 CR3: 000000022cca8004 CR4: 00000000003706e0
+ [13367.706565] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ [13367.707127] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ [13367.707686] Call Trace:
+ [13367.708246] ? ___slab_alloc+0x395/0x740
+ [13367.708820] ? reada_add_block+0xae/0xee0 [btrfs]
+ [13367.709383] lock_acquire+0xb1/0x480
+ [13367.709955] ? reada_add_block+0xe0/0xee0 [btrfs]
+ [13367.710537] ? reada_add_block+0xae/0xee0 [btrfs]
+ [13367.711097] ? rcu_read_lock_sched_held+0x5d/0x90
+ [13367.711659] ? kmem_cache_alloc_trace+0x8d2/0x990
+ [13367.712221] ? lock_acquired+0x33b/0x470
+ [13367.712784] _raw_spin_lock+0x34/0x80
+ [13367.713356] ? reada_add_block+0xe0/0xee0 [btrfs]
+ [13367.713966] reada_add_block+0xe0/0xee0 [btrfs]
+ [13367.714529] ? btrfs_root_node+0x15/0x1f0 [btrfs]
+ [13367.715077] btrfs_reada_add+0x117/0x170 [btrfs]
+ [13367.715620] scrub_stripe+0x21e/0x10d0 [btrfs]
+ [13367.716141] ? kvm_sched_clock_read+0x5/0x10
+ [13367.716657] ? __lock_acquire+0x41e/0x3970
+ [13367.717184] ? scrub_chunk+0x60/0x140 [btrfs]
+ [13367.717697] ? find_held_lock+0x32/0x90
+ [13367.718254] ? scrub_chunk+0x60/0x140 [btrfs]
+ [13367.718773] ? lock_acquired+0x33b/0x470
+ [13367.719278] ? scrub_chunk+0xcd/0x140 [btrfs]
+ [13367.719786] scrub_chunk+0xcd/0x140 [btrfs]
+ [13367.720291] scrub_enumerate_chunks+0x270/0x5c0 [btrfs]
+ [13367.720787] ? finish_wait+0x90/0x90
+ [13367.721281] btrfs_scrub_dev+0x1ee/0x620 [btrfs]
+ [13367.721762] ? rcu_read_lock_any_held+0x8e/0xb0
+ [13367.722235] ? preempt_count_add+0x49/0xa0
+ [13367.722710] ? __sb_start_write+0x19b/0x290
+ [13367.723192] btrfs_ioctl+0x7f5/0x36f0 [btrfs]
+ [13367.723660] ? __fget_files+0x101/0x1d0
+ [13367.724118] ? find_held_lock+0x32/0x90
+ [13367.724559] ? __fget_files+0x101/0x1d0
+ [13367.724982] ? __x64_sys_ioctl+0x83/0xb0
+ [13367.725399] __x64_sys_ioctl+0x83/0xb0
+ [13367.725802] do_syscall_64+0x33/0x80
+ [13367.726188] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ [13367.726574] RIP: 0033:0x7fe1df7add87
+ [13367.726948] Code: 00 00 00 48 8b 05 09 91 (...)
+ [13367.727763] RSP: 002b:00007fe1df6b4d48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+ [13367.728179] RAX: ffffffffffffffda RBX: 000055ce1fb596a0 RCX: 00007fe1df7add87
+ [13367.728604] RDX: 000055ce1fb596a0 RSI: 00000000c400941b RDI: 0000000000000003
+ [13367.729021] RBP: 0000000000000000 R08: 00007fe1df6b5700 R09: 0000000000000000
+ [13367.729431] R10: 00007fe1df6b5700 R11: 0000000000000246 R12: 00007ffd922b07de
+ [13367.729842] R13: 00007ffd922b07df R14: 00007fe1df6b4e40 R15: 0000000000802000
+ [13367.730275] Modules linked in: btrfs blake2b_generic xor (...)
+ [13367.732638] CR2: 00000000000000b0
+ [13367.733166] ---[ end trace d298b6805556acd9 ]---
+
+What happens is the following:
+
+1) At reada_find_extent() we don't find any existing readahead extent for
+ the metadata extent starting at logical address X;
+
+2) So we proceed to create a new one. We then call btrfs_map_block() to get
+ information about which stripes contain extent X;
+
+3) After that we iterate over the stripes and create only one zone for the
+ readahead extent - only one because reada_find_zone() returned NULL for
+ all iterations except for one, either because a memory allocation failed
+ or it couldn't find the block group of the extent (it may have just been
+ deleted);
+
+4) We then add the new readahead extent to the readahead extents radix
+ tree at fs_info->reada_tree;
+
+5) Then we iterate over each zone of the new readahead extent, and find
+ that the device used for that zone no longer exists, because it was
+ removed or it was the source device of a device replace operation.
+ Since this left 'have_zone' set to 0, after finishing the loop we jump
+ to the 'error' label, call kfree() on the new readahead extent and
+ return without removing it from the radix tree at fs_info->reada_tree;
+
+6) Any future call to reada_find_extent() for the logical address X will
+ find the stale pointer in the readahead extents radix tree, increment
+ its reference counter, which can trigger the use-after-free right
+ away or return it to the caller reada_add_block() that results in the
+ use-after-free of the example trace above.
+
+So fix this by making sure we delete the readahead extent from the radix
+tree if we fail to setup zones for it (when 'have_zone = 0').
+
+Fixes: 319450211842ba ("btrfs: reada: bypass adding extent when all zone failed")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/reada.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/reada.c
++++ b/fs/btrfs/reada.c
+@@ -456,6 +456,8 @@ static struct reada_extent *reada_find_e
+ }
+ have_zone = 1;
+ }
++ if (!have_zone)
++ radix_tree_delete(&fs_info->reada_tree, index);
+ spin_unlock(&fs_info->reada_lock);
+ btrfs_dev_replace_unlock(&fs_info->dev_replace, 0);
+
--- /dev/null
+From bb56f02f26fe23798edb1b2175707419b28c752a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 14 Sep 2020 15:27:50 +0100
+Subject: btrfs: reschedule if necessary when logging directory items
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit bb56f02f26fe23798edb1b2175707419b28c752a upstream.
+
+Logging directories with many entries can take a significant amount of
+time, and in some cases monopolize a cpu/core for a long time if the
+logging task doesn't happen to block often enough.
+
+Johannes and Lu Fengqi reported test case generic/041 triggering a soft
+lockup when the kernel has CONFIG_SOFTLOCKUP_DETECTOR=y. For this test
+case we log an inode with 3002 hard links, and because the test removed
+one hard link before fsyncing the file, the inode logging causes the
+parent directory do be logged as well, which has 6004 directory items to
+log (3002 BTRFS_DIR_ITEM_KEY items plus 3002 BTRFS_DIR_INDEX_KEY items),
+so it can take a significant amount of time and trigger the soft lockup.
+
+So just make tree-log.c:log_dir_items() reschedule when necessary,
+releasing the current search path before doing so and then resume from
+where it was before the reschedule.
+
+The stack trace produced when the soft lockup happens is the following:
+
+[10480.277653] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [xfs_io:28172]
+[10480.279418] Modules linked in: dm_thin_pool dm_persistent_data (...)
+[10480.284915] irq event stamp: 29646366
+[10480.285987] hardirqs last enabled at (29646365): [<ffffffff85249b66>] __slab_alloc.constprop.0+0x56/0x60
+[10480.288482] hardirqs last disabled at (29646366): [<ffffffff8579b00d>] irqentry_enter+0x1d/0x50
+[10480.290856] softirqs last enabled at (4612): [<ffffffff85a00323>] __do_softirq+0x323/0x56c
+[10480.293615] softirqs last disabled at (4483): [<ffffffff85800dbf>] asm_call_on_stack+0xf/0x20
+[10480.296428] CPU: 2 PID: 28172 Comm: xfs_io Not tainted 5.9.0-rc4-default+ #1248
+[10480.298948] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
+[10480.302455] RIP: 0010:__slab_alloc.constprop.0+0x19/0x60
+[10480.304151] Code: 86 e8 31 75 21 00 66 66 2e 0f 1f 84 00 00 00 (...)
+[10480.309558] RSP: 0018:ffffadbe09397a58 EFLAGS: 00000282
+[10480.311179] RAX: ffff8a495ab92840 RBX: 0000000000000282 RCX: 0000000000000006
+[10480.313242] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff85249b66
+[10480.315260] RBP: ffff8a497d04b740 R08: 0000000000000001 R09: 0000000000000001
+[10480.317229] R10: ffff8a497d044800 R11: ffff8a495ab93c40 R12: 0000000000000000
+[10480.319169] R13: 0000000000000000 R14: 0000000000000c40 R15: ffffffffc01daf70
+[10480.321104] FS: 00007fa1dc5c0e40(0000) GS:ffff8a497da00000(0000) knlGS:0000000000000000
+[10480.323559] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[10480.325235] CR2: 00007fa1dc5befb8 CR3: 0000000004f8a006 CR4: 0000000000170ea0
+[10480.327259] Call Trace:
+[10480.328286] ? overwrite_item+0x1f0/0x5a0 [btrfs]
+[10480.329784] __kmalloc+0x831/0xa20
+[10480.331009] ? btrfs_get_32+0xb0/0x1d0 [btrfs]
+[10480.332464] overwrite_item+0x1f0/0x5a0 [btrfs]
+[10480.333948] log_dir_items+0x2ee/0x570 [btrfs]
+[10480.335413] log_directory_changes+0x82/0xd0 [btrfs]
+[10480.336926] btrfs_log_inode+0xc9b/0xda0 [btrfs]
+[10480.338374] ? init_once+0x20/0x20 [btrfs]
+[10480.339711] btrfs_log_inode_parent+0x8d3/0xd10 [btrfs]
+[10480.341257] ? dget_parent+0x97/0x2e0
+[10480.342480] btrfs_log_dentry_safe+0x3a/0x50 [btrfs]
+[10480.343977] btrfs_sync_file+0x24b/0x5e0 [btrfs]
+[10480.345381] do_fsync+0x38/0x70
+[10480.346483] __x64_sys_fsync+0x10/0x20
+[10480.347703] do_syscall_64+0x2d/0x70
+[10480.348891] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+[10480.350444] RIP: 0033:0x7fa1dc80970b
+[10480.351642] Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 (...)
+[10480.356952] RSP: 002b:00007fffb3d081d0 EFLAGS: 00000293 ORIG_RAX: 000000000000004a
+[10480.359458] RAX: ffffffffffffffda RBX: 0000562d93d45e40 RCX: 00007fa1dc80970b
+[10480.361426] RDX: 0000562d93d44ab0 RSI: 0000562d93d45e60 RDI: 0000000000000003
+[10480.363367] RBP: 0000000000000001 R08: 0000000000000000 R09: 00007fa1dc7b2a40
+[10480.365317] R10: 0000562d93d0e366 R11: 0000000000000293 R12: 0000000000000001
+[10480.367299] R13: 0000562d93d45290 R14: 0000562d93d45e40 R15: 0000562d93d45e60
+
+Link: https://lore.kernel.org/linux-btrfs/20180713090216.GC575@fnst.localdomain/
+Reported-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+CC: stable@vger.kernel.org # 4.4+
+Tested-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/tree-log.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -3478,6 +3478,7 @@ static noinline int log_dir_items(struct
+ * search and this search we'll not find the key again and can just
+ * bail.
+ */
++search:
+ ret = btrfs_search_slot(NULL, root, &min_key, path, 0, 0);
+ if (ret != 0)
+ goto done;
+@@ -3497,6 +3498,13 @@ static noinline int log_dir_items(struct
+
+ if (min_key.objectid != ino || min_key.type != key_type)
+ goto done;
++
++ if (need_resched()) {
++ btrfs_release_path(path);
++ cond_resched();
++ goto search;
++ }
++
+ ret = overwrite_item(trans, log, dst_path, src, i,
+ &min_key);
+ if (ret) {
--- /dev/null
+From 9c2b4e0347067396ceb3ae929d6888c81d610259 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 21 Sep 2020 14:13:30 +0100
+Subject: btrfs: send, recompute reference path after orphanization of a directory
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 9c2b4e0347067396ceb3ae929d6888c81d610259 upstream.
+
+During an incremental send, when an inode has multiple new references we
+might end up emitting rename operations for orphanizations that have a
+source path that is no longer valid due to a previous orphanization of
+some directory inode. This causes the receiver to fail since it tries
+to rename a path that does not exists.
+
+Example reproducer:
+
+ $ cat reproducer.sh
+ #!/bin/bash
+
+ mkfs.btrfs -f /dev/sdi >/dev/null
+ mount /dev/sdi /mnt/sdi
+
+ touch /mnt/sdi/f1
+ touch /mnt/sdi/f2
+ mkdir /mnt/sdi/d1
+ mkdir /mnt/sdi/d1/d2
+
+ # Filesystem looks like:
+ #
+ # . (ino 256)
+ # |----- f1 (ino 257)
+ # |----- f2 (ino 258)
+ # |----- d1/ (ino 259)
+ # |----- d2/ (ino 260)
+
+ btrfs subvolume snapshot -r /mnt/sdi /mnt/sdi/snap1
+ btrfs send -f /tmp/snap1.send /mnt/sdi/snap1
+
+ # Now do a series of changes such that:
+ #
+ # *) inode 258 has one new hardlink and the previous name changed
+ #
+ # *) both names conflict with the old names of two other inodes:
+ #
+ # 1) the new name "d1" conflicts with the old name of inode 259,
+ # under directory inode 256 (root)
+ #
+ # 2) the new name "d2" conflicts with the old name of inode 260
+ # under directory inode 259
+ #
+ # *) inodes 259 and 260 now have the old names of inode 258
+ #
+ # *) inode 257 is now located under inode 260 - an inode with a number
+ # smaller than the inode (258) for which we created a second hard
+ # link and swapped its names with inodes 259 and 260
+ #
+ ln /mnt/sdi/f2 /mnt/sdi/d1/f2_link
+ mv /mnt/sdi/f1 /mnt/sdi/d1/d2/f1
+
+ # Swap d1 and f2.
+ mv /mnt/sdi/d1 /mnt/sdi/tmp
+ mv /mnt/sdi/f2 /mnt/sdi/d1
+ mv /mnt/sdi/tmp /mnt/sdi/f2
+
+ # Swap d2 and f2_link
+ mv /mnt/sdi/f2/d2 /mnt/sdi/tmp
+ mv /mnt/sdi/f2/f2_link /mnt/sdi/f2/d2
+ mv /mnt/sdi/tmp /mnt/sdi/f2/f2_link
+
+ # Filesystem now looks like:
+ #
+ # . (ino 256)
+ # |----- d1 (ino 258)
+ # |----- f2/ (ino 259)
+ # |----- f2_link/ (ino 260)
+ # | |----- f1 (ino 257)
+ # |
+ # |----- d2 (ino 258)
+
+ btrfs subvolume snapshot -r /mnt/sdi /mnt/sdi/snap2
+ btrfs send -f /tmp/snap2.send -p /mnt/sdi/snap1 /mnt/sdi/snap2
+
+ mkfs.btrfs -f /dev/sdj >/dev/null
+ mount /dev/sdj /mnt/sdj
+
+ btrfs receive -f /tmp/snap1.send /mnt/sdj
+ btrfs receive -f /tmp/snap2.send /mnt/sdj
+
+ umount /mnt/sdi
+ umount /mnt/sdj
+
+When executed the receive of the incremental stream fails:
+
+ $ ./reproducer.sh
+ Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1'
+ At subvol /mnt/sdi/snap1
+ Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2'
+ At subvol /mnt/sdi/snap2
+ At subvol snap1
+ At snapshot snap2
+ ERROR: rename d1/d2 -> o260-6-0 failed: No such file or directory
+
+This happens because:
+
+1) When processing inode 257 we end up computing the name for inode 259
+ because it is an ancestor in the send snapshot, and at that point it
+ still has its old name, "d1", from the parent snapshot because inode
+ 259 was not yet processed. We then cache that name, which is valid
+ until we start processing inode 259 (or set the progress to 260 after
+ processing its references);
+
+2) Later we start processing inode 258 and collecting all its new
+ references into the list sctx->new_refs. The first reference in the
+ list happens to be the reference for name "d1" while the reference for
+ name "d2" is next (the last element of the list).
+ We compute the full path "d1/d2" for this second reference and store
+ it in the reference (its ->full_path member). The path used for the
+ new parent directory was "d1" and not "f2" because inode 259, the
+ new parent, was not yet processed;
+
+3) When we start processing the new references at process_recorded_refs()
+ we start with the first reference in the list, for the new name "d1".
+ Because there is a conflicting inode that was not yet processed, which
+ is directory inode 259, we orphanize it, renaming it from "d1" to
+ "o259-6-0";
+
+4) Then we start processing the new reference for name "d2", and we
+ realize it conflicts with the reference of inode 260 in the parent
+ snapshot. So we issue an orphanization operation for inode 260 by
+ emitting a rename operation with a destination path of "o260-6-0"
+ and a source path of "d1/d2" - this source path is the value we
+ stored in the reference earlier at step 2), corresponding to the
+ ->full_path member of the reference, however that path is no longer
+ valid due to the orphanization of the directory inode 259 in step 3).
+ This makes the receiver fail since the path does not exists, it should
+ have been "o259-6-0/d2".
+
+Fix this by recomputing the full path of a reference before emitting an
+orphanization if we previously orphanized any directory, since that
+directory could be a parent in the new path. This is a rare scenario so
+keeping it simple and not checking if that previously orphanized directory
+is in fact an ancestor of the inode we are trying to orphanize.
+
+A test case for fstests follows soon.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/send.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 72 insertions(+)
+
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -3821,6 +3821,72 @@ static int update_ref_path(struct send_c
+ }
+
+ /*
++ * When processing the new references for an inode we may orphanize an existing
++ * directory inode because its old name conflicts with one of the new references
++ * of the current inode. Later, when processing another new reference of our
++ * inode, we might need to orphanize another inode, but the path we have in the
++ * reference reflects the pre-orphanization name of the directory we previously
++ * orphanized. For example:
++ *
++ * parent snapshot looks like:
++ *
++ * . (ino 256)
++ * |----- f1 (ino 257)
++ * |----- f2 (ino 258)
++ * |----- d1/ (ino 259)
++ * |----- d2/ (ino 260)
++ *
++ * send snapshot looks like:
++ *
++ * . (ino 256)
++ * |----- d1 (ino 258)
++ * |----- f2/ (ino 259)
++ * |----- f2_link/ (ino 260)
++ * | |----- f1 (ino 257)
++ * |
++ * |----- d2 (ino 258)
++ *
++ * When processing inode 257 we compute the name for inode 259 as "d1", and we
++ * cache it in the name cache. Later when we start processing inode 258, when
++ * collecting all its new references we set a full path of "d1/d2" for its new
++ * reference with name "d2". When we start processing the new references we
++ * start by processing the new reference with name "d1", and this results in
++ * orphanizing inode 259, since its old reference causes a conflict. Then we
++ * move on the next new reference, with name "d2", and we find out we must
++ * orphanize inode 260, as its old reference conflicts with ours - but for the
++ * orphanization we use a source path corresponding to the path we stored in the
++ * new reference, which is "d1/d2" and not "o259-6-0/d2" - this makes the
++ * receiver fail since the path component "d1/" no longer exists, it was renamed
++ * to "o259-6-0/" when processing the previous new reference. So in this case we
++ * must recompute the path in the new reference and use it for the new
++ * orphanization operation.
++ */
++static int refresh_ref_path(struct send_ctx *sctx, struct recorded_ref *ref)
++{
++ char *name;
++ int ret;
++
++ name = kmemdup(ref->name, ref->name_len, GFP_KERNEL);
++ if (!name)
++ return -ENOMEM;
++
++ fs_path_reset(ref->full_path);
++ ret = get_cur_path(sctx, ref->dir, ref->dir_gen, ref->full_path);
++ if (ret < 0)
++ goto out;
++
++ ret = fs_path_add(ref->full_path, name, ref->name_len);
++ if (ret < 0)
++ goto out;
++
++ /* Update the reference's base name pointer. */
++ set_ref_path(ref, ref->full_path);
++out:
++ kfree(name);
++ return ret;
++}
++
++/*
+ * This does all the move/link/unlink/rmdir magic.
+ */
+ static int process_recorded_refs(struct send_ctx *sctx, int *pending_move)
+@@ -3950,6 +4016,12 @@ static int process_recorded_refs(struct
+ struct name_cache_entry *nce;
+ struct waiting_dir_move *wdm;
+
++ if (orphanized_dir) {
++ ret = refresh_ref_path(sctx, cur);
++ if (ret < 0)
++ goto out;
++ }
++
+ ret = orphanize_inode(sctx, ow_inode, ow_gen,
+ cur->full_path);
+ if (ret < 0)
--- /dev/null
+From 8eb2fd00153a3a96a19c62ac9c6d48c2efebe5e8 Mon Sep 17 00:00:00 2001
+From: Denis Efremov <efremov@linux.com>
+Date: Mon, 21 Sep 2020 20:03:35 +0300
+Subject: btrfs: use kvzalloc() to allocate clone_roots in btrfs_ioctl_send()
+
+From: Denis Efremov <efremov@linux.com>
+
+commit 8eb2fd00153a3a96a19c62ac9c6d48c2efebe5e8 upstream.
+
+btrfs_ioctl_send() used open-coded kvzalloc implementation earlier.
+The code was accidentally replaced with kzalloc() call [1]. Restore
+the original code by using kvzalloc() to allocate sctx->clone_roots.
+
+[1] https://patchwork.kernel.org/patch/9757891/#20529627
+
+Fixes: 818e010bf9d0 ("btrfs: replace opencoded kvzalloc with the helper")
+CC: stable@vger.kernel.org # 4.14+
+Signed-off-by: Denis Efremov <efremov@linux.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/send.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -6701,7 +6701,7 @@ long btrfs_ioctl_send(struct file *mnt_f
+
+ alloc_size = sizeof(struct clone_root) * (arg->clone_sources_count + 1);
+
+- sctx->clone_roots = kzalloc(alloc_size, GFP_KERNEL);
++ sctx->clone_roots = kvzalloc(alloc_size, GFP_KERNEL);
+ if (!sctx->clone_roots) {
+ ret = -ENOMEM;
+ goto out;
--- /dev/null
+From baf6fd97b16ea8f981b8a8b04039596f32fc2972 Mon Sep 17 00:00:00 2001
+From: Paul Cercueil <paul@crapouillou.net>
+Date: Sun, 4 Oct 2020 16:03:07 +0200
+Subject: dmaengine: dma-jz4780: Fix race in jz4780_dma_tx_status
+
+From: Paul Cercueil <paul@crapouillou.net>
+
+commit baf6fd97b16ea8f981b8a8b04039596f32fc2972 upstream.
+
+The jz4780_dma_tx_status() function would check if a channel's cookie
+state was set to 'completed', and if not, it would enter the critical
+section. However, in that time frame, the jz4780_dma_chan_irq() function
+was able to set the cookie to 'completed', and clear the jzchan->vchan
+pointer, which was deferenced in the critical section of the first
+function.
+
+Fix this race by checking the channel's cookie state after entering the
+critical function and not before.
+
+Fixes: d894fc6046fe ("dmaengine: jz4780: add driver for the Ingenic JZ4780 DMA controller")
+Cc: stable@vger.kernel.org # v4.0
+Signed-off-by: Paul Cercueil <paul@crapouillou.net>
+Reported-by: Artur Rojek <contact@artur-rojek.eu>
+Tested-by: Artur Rojek <contact@artur-rojek.eu>
+Link: https://lore.kernel.org/r/20201004140307.885556-1-paul@crapouillou.net
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/dma-jz4780.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/dma/dma-jz4780.c
++++ b/drivers/dma/dma-jz4780.c
+@@ -567,11 +567,11 @@ static enum dma_status jz4780_dma_tx_sta
+ enum dma_status status;
+ unsigned long flags;
+
++ spin_lock_irqsave(&jzchan->vchan.lock, flags);
++
+ status = dma_cookie_status(chan, cookie, txstate);
+ if ((status == DMA_COMPLETE) || (txstate == NULL))
+- return status;
+-
+- spin_lock_irqsave(&jzchan->vchan.lock, flags);
++ goto out_unlock_irqrestore;
+
+ vdesc = vchan_find_desc(&jzchan->vchan, cookie);
+ if (vdesc) {
+@@ -588,6 +588,7 @@ static enum dma_status jz4780_dma_tx_sta
+ && jzchan->desc->status & (JZ_DMA_DCS_AR | JZ_DMA_DCS_HLT))
+ status = DMA_ERROR;
+
++out_unlock_irqrestore:
+ spin_unlock_irqrestore(&jzchan->vchan.lock, flags);
+ return status;
+ }
--- /dev/null
+From 8195400f7ea95399f721ad21f4d663a62c65036f Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Mon, 19 Oct 2020 11:15:23 +0100
+Subject: drm/i915: Force VT'd workarounds when running as a guest OS
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit 8195400f7ea95399f721ad21f4d663a62c65036f upstream.
+
+If i915.ko is being used as a passthrough device, it does not know if
+the host is using intel_iommu. Mixing the iommu and gfx causes a few
+issues (such as scanout overfetch) which we need to workaround inside
+the driver, so if we detect we are running under a hypervisor, also
+assume the device access is being virtualised.
+
+Reported-by: Stefan Fritsch <sf@sfritsch.de>
+Suggested-by: Stefan Fritsch <sf@sfritsch.de>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Stefan Fritsch <sf@sfritsch.de>
+Cc: stable@vger.kernel.org
+Tested-by: Stefan Fritsch <sf@sfritsch.de>
+Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201019101523.4145-1-chris@chris-wilson.co.uk
+(cherry picked from commit f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_drv.h
++++ b/drivers/gpu/drm/i915/i915_drv.h
+@@ -33,6 +33,8 @@
+ #include <uapi/drm/i915_drm.h>
+ #include <uapi/drm/drm_fourcc.h>
+
++#include <asm/hypervisor.h>
++
+ #include <linux/io-mapping.h>
+ #include <linux/i2c.h>
+ #include <linux/i2c-algo-bit.h>
+@@ -3141,7 +3143,9 @@ static inline bool intel_vtd_active(void
+ if (intel_iommu_gfx_mapped)
+ return true;
+ #endif
+- return false;
++
++ /* Running as a guest, we assume the host is enforcing VT'd */
++ return !hypervisor_is_type(X86_HYPER_NATIVE);
+ }
+
+ static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private *dev_priv)
--- /dev/null
+From 6dbf7bb555981fb5faf7b691e8f6169fc2b2e63b Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Fri, 4 Sep 2020 10:58:51 +0200
+Subject: fs: Don't invalidate page buffers in block_write_full_page()
+
+From: Jan Kara <jack@suse.cz>
+
+commit 6dbf7bb555981fb5faf7b691e8f6169fc2b2e63b upstream.
+
+If block_write_full_page() is called for a page that is beyond current
+inode size, it will truncate page buffers for the page and return 0.
+This logic has been added in 2.5.62 in commit 81eb69062588 ("fix ext3
+BUG due to race with truncate") in history.git tree to fix a problem
+with ext3 in data=ordered mode. This particular problem doesn't exist
+anymore because ext3 is long gone and ext4 handles ordered data
+differently. Also normally buffers are invalidated by truncate code and
+there's no need to specially handle this in ->writepage() code.
+
+This invalidation of page buffers in block_write_full_page() is causing
+issues to filesystems (e.g. ext4 or ocfs2) when block device is shrunk
+under filesystem's hands and metadata buffers get discarded while being
+tracked by the journalling layer. Although it is obviously "not
+supported" it can cause kernel crashes like:
+
+[ 7986.689400] BUG: unable to handle kernel NULL pointer dereference at
++0000000000000008
+[ 7986.697197] PGD 0 P4D 0
+[ 7986.699724] Oops: 0002 [#1] SMP PTI
+[ 7986.703200] CPU: 4 PID: 203778 Comm: jbd2/dm-3-8 Kdump: loaded Tainted: G
++O --------- - - 4.18.0-147.5.0.5.h126.eulerosv2r9.x86_64 #1
+[ 7986.716438] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015
+[ 7986.723462] RIP: 0010:jbd2_journal_grab_journal_head+0x1b/0x40 [jbd2]
+...
+[ 7986.810150] Call Trace:
+[ 7986.812595] __jbd2_journal_insert_checkpoint+0x23/0x70 [jbd2]
+[ 7986.818408] jbd2_journal_commit_transaction+0x155f/0x1b60 [jbd2]
+[ 7986.836467] kjournald2+0xbd/0x270 [jbd2]
+
+which is not great. The crash happens because bh->b_private is suddently
+NULL although BH_JBD flag is still set (this is because
+block_invalidatepage() cleared BH_Mapped flag and subsequent bh lookup
+found buffer without BH_Mapped set, called init_page_buffers() which has
+rewritten bh->b_private). So just remove the invalidation in
+block_write_full_page().
+
+Note that the buffer cache invalidation when block device changes size
+is already careful to avoid similar problems by using
+invalidate_mapping_pages() which skips busy buffers so it was only this
+odd block_write_full_page() behavior that could tear down bdev buffers
+under filesystem's hands.
+
+Reported-by: Ye Bin <yebin10@huawei.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+CC: stable@vger.kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/buffer.c | 16 ----------------
+ 1 file changed, 16 deletions(-)
+
+--- a/fs/buffer.c
++++ b/fs/buffer.c
+@@ -2799,16 +2799,6 @@ int nobh_writepage(struct page *page, ge
+ /* Is the page fully outside i_size? (truncate in progress) */
+ offset = i_size & (PAGE_SIZE-1);
+ if (page->index >= end_index+1 || !offset) {
+- /*
+- * The page may have dirty, unmapped buffers. For example,
+- * they may have been added in ext3_writepage(). Make them
+- * freeable here, so the page does not leak.
+- */
+-#if 0
+- /* Not really sure about this - do we need this ? */
+- if (page->mapping->a_ops->invalidatepage)
+- page->mapping->a_ops->invalidatepage(page, offset);
+-#endif
+ unlock_page(page);
+ return 0; /* don't care */
+ }
+@@ -3003,12 +2993,6 @@ int block_write_full_page(struct page *p
+ /* Is the page fully outside i_size? (truncate in progress) */
+ offset = i_size & (PAGE_SIZE-1);
+ if (page->index >= end_index+1 || !offset) {
+- /*
+- * The page may have dirty, unmapped buffers. For example,
+- * they may have been added in ext3_writepage(). Make them
+- * freeable here, so the page does not leak.
+- */
+- do_invalidatepage(page, 0, PAGE_SIZE);
+ unlock_page(page);
+ return 0; /* don't care */
+ }
--- /dev/null
+From 39e91f3be4cba51c1560bcda3a343ed1f64dc916 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:51:00 +0100
+Subject: iio:adc:ti-adc0832 Fix alignment issue with timestamp
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 39e91f3be4cba51c1560bcda3a343ed1f64dc916 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses an array of smaller elements on the stack.
+
+We fix this issues by moving to a suitable structure in the iio_priv()
+data with alignment explicitly requested. This data is allocated
+with kzalloc so no data can leak apart from previous readings.
+Note that previously no data could leak 'including' previous readings
+but I don't think it is an issue to potentially leak them like
+this now does.
+
+In this case the postioning of the timestamp is depends on what
+other channels are enabled. As such we cannot use a structure to
+make the alignment explicit as it would be missleading by suggesting
+only one possible location for the timestamp.
+
+Fixes: 815bbc87462a ("iio: ti-adc0832: add triggered buffer support")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Akinobu Mita <akinobu.mita@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200722155103.979802-25-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ti-adc0832.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/adc/ti-adc0832.c
++++ b/drivers/iio/adc/ti-adc0832.c
+@@ -31,6 +31,12 @@ struct adc0832 {
+ struct regulator *reg;
+ struct mutex lock;
+ u8 mux_bits;
++ /*
++ * Max size needed: 16x 1 byte ADC data + 8 bytes timestamp
++ * May be shorter if not all channels are enabled subject
++ * to the timestamp remaining 8 byte aligned.
++ */
++ u8 data[24] __aligned(8);
+
+ u8 tx_buf[2] ____cacheline_aligned;
+ u8 rx_buf[2];
+@@ -203,7 +209,6 @@ static irqreturn_t adc0832_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct adc0832 *adc = iio_priv(indio_dev);
+- u8 data[24] = { }; /* 16x 1 byte ADC data + 8 bytes timestamp */
+ int scan_index;
+ int i = 0;
+
+@@ -221,10 +226,10 @@ static irqreturn_t adc0832_trigger_handl
+ goto out;
+ }
+
+- data[i] = ret;
++ adc->data[i] = ret;
+ i++;
+ }
+- iio_push_to_buffers_with_timestamp(indio_dev, data,
++ iio_push_to_buffers_with_timestamp(indio_dev, adc->data,
+ iio_get_time_ns(indio_dev));
+ out:
+ mutex_unlock(&adc->lock);
--- /dev/null
+From 293e809b2e8e608b65a949101aaf7c0bd1224247 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:51:01 +0100
+Subject: iio:adc:ti-adc12138 Fix alignment issue with timestamp
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 293e809b2e8e608b65a949101aaf7c0bd1224247 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses an array of smaller elements on the stack.
+
+We move to a suitable structure in the iio_priv() data with alignment
+explicitly requested. This data is allocated with kzalloc so no
+data can leak apart from previous readings. Note that previously
+no leak at all could occur, but previous readings should never
+be a problem.
+
+In this case the timestamp location depends on what other channels
+are enabled. As such we can't use a structure without misleading
+by suggesting only one possible timestamp location.
+
+Fixes: 50a6edb1b6e0 ("iio: adc: add ADC12130/ADC12132/ADC12138 ADC driver")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Akinobu Mita <akinobu.mita@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200722155103.979802-26-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/ti-adc12138.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/adc/ti-adc12138.c
++++ b/drivers/iio/adc/ti-adc12138.c
+@@ -50,6 +50,12 @@ struct adc12138 {
+ struct completion complete;
+ /* The number of cclk periods for the S/H's acquisition time */
+ unsigned int acquisition_time;
++ /*
++ * Maximum size needed: 16x 2 bytes ADC data + 8 bytes timestamp.
++ * Less may be need if not all channels are enabled, as long as
++ * the 8 byte alignment of the timestamp is maintained.
++ */
++ __be16 data[20] __aligned(8);
+
+ u8 tx_buf[2] ____cacheline_aligned;
+ u8 rx_buf[2];
+@@ -333,7 +339,6 @@ static irqreturn_t adc12138_trigger_hand
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct adc12138 *adc = iio_priv(indio_dev);
+- __be16 data[20] = { }; /* 16x 2 bytes ADC data + 8 bytes timestamp */
+ __be16 trash;
+ int ret;
+ int scan_index;
+@@ -349,7 +354,7 @@ static irqreturn_t adc12138_trigger_hand
+ reinit_completion(&adc->complete);
+
+ ret = adc12138_start_and_read_conv(adc, scan_chan,
+- i ? &data[i - 1] : &trash);
++ i ? &adc->data[i - 1] : &trash);
+ if (ret) {
+ dev_warn(&adc->spi->dev,
+ "failed to start conversion\n");
+@@ -366,7 +371,7 @@ static irqreturn_t adc12138_trigger_hand
+ }
+
+ if (i) {
+- ret = adc12138_read_conv_data(adc, &data[i - 1]);
++ ret = adc12138_read_conv_data(adc, &adc->data[i - 1]);
+ if (ret) {
+ dev_warn(&adc->spi->dev,
+ "failed to get conversion data\n");
+@@ -374,7 +379,7 @@ static irqreturn_t adc12138_trigger_hand
+ }
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, data,
++ iio_push_to_buffers_with_timestamp(indio_dev, adc->data,
+ iio_get_time_ns(indio_dev));
+ out:
+ mutex_unlock(&adc->lock);
--- /dev/null
+From 10ab7cfd5522f0041028556dac864a003e158556 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:41 +0100
+Subject: iio:gyro:itg3200: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 10ab7cfd5522f0041028556dac864a003e158556 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses a 16 byte array of smaller elements on the stack.
+This is fixed by using an explicit c structure. As there are no
+holes in the structure, there is no possiblity of data leakage
+in this case.
+
+The explicit alignment of ts is not strictly necessary but potentially
+makes the code slightly less fragile. It also removes the possibility
+of this being cut and paste into another driver where the alignment
+isn't already true.
+
+Fixes: 36e0371e7764 ("iio:itg3200: Use iio_push_to_buffers_with_timestamp()")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200722155103.979802-6-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/gyro/itg3200_buffer.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/iio/gyro/itg3200_buffer.c
++++ b/drivers/iio/gyro/itg3200_buffer.c
+@@ -49,13 +49,20 @@ static irqreturn_t itg3200_trigger_handl
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct itg3200 *st = iio_priv(indio_dev);
+- __be16 buf[ITG3200_SCAN_ELEMENTS + sizeof(s64)/sizeof(u16)];
++ /*
++ * Ensure correct alignment and padding including for the
++ * timestamp that may be inserted.
++ */
++ struct {
++ __be16 buf[ITG3200_SCAN_ELEMENTS];
++ s64 ts __aligned(8);
++ } scan;
+
+- int ret = itg3200_read_all_channels(st->i2c, buf);
++ int ret = itg3200_read_all_channels(st->i2c, scan.buf);
+ if (ret < 0)
+ goto error_ret;
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buf, pf->timestamp);
++ iio_push_to_buffers_with_timestamp(indio_dev, &scan, pf->timestamp);
+
+ iio_trigger_notify_done(indio_dev->trig);
+
--- /dev/null
+From 0456ecf34d466261970e0ff92b2b9c78a4908637 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Wed, 22 Jul 2020 16:50:44 +0100
+Subject: iio:light:si1145: Fix timestamp alignment and prevent data leak.
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 0456ecf34d466261970e0ff92b2b9c78a4908637 upstream.
+
+One of a class of bugs pointed out by Lars in a recent review.
+iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
+to the size of the timestamp (8 bytes). This is not guaranteed in
+this driver which uses a 24 byte array of smaller elements on the stack.
+As Lars also noted this anti pattern can involve a leak of data to
+userspace and that indeed can happen here. We close both issues by
+moving to a suitable array in the iio_priv() data with alignment
+explicitly requested. This data is allocated with kzalloc so no
+data can leak appart from previous readings.
+
+Depending on the enabled channels, the location of the timestamp
+can be at various aligned offsets through the buffer. As such we
+any use of a structure to enforce this alignment would incorrectly
+suggest a single location for the timestamp. Comments adjusted to
+express this clearly in the code.
+
+Fixes: ac45e57f1590 ("iio: light: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors")
+Reported-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200722155103.979802-9-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/light/si1145.c | 19 +++++++++++--------
+ 1 file changed, 11 insertions(+), 8 deletions(-)
+
+--- a/drivers/iio/light/si1145.c
++++ b/drivers/iio/light/si1145.c
+@@ -172,6 +172,7 @@ struct si1145_part_info {
+ * @part_info: Part information
+ * @trig: Pointer to iio trigger
+ * @meas_rate: Value of MEAS_RATE register. Only set in HW in auto mode
++ * @buffer: Used to pack data read from sensor.
+ */
+ struct si1145_data {
+ struct i2c_client *client;
+@@ -183,6 +184,14 @@ struct si1145_data {
+ bool autonomous;
+ struct iio_trigger *trig;
+ int meas_rate;
++ /*
++ * Ensure timestamp will be naturally aligned if present.
++ * Maximum buffer size (may be only partly used if not all
++ * channels are enabled):
++ * 6*2 bytes channels data + 4 bytes alignment +
++ * 8 bytes timestamp
++ */
++ u8 buffer[24] __aligned(8);
+ };
+
+ /**
+@@ -444,12 +453,6 @@ static irqreturn_t si1145_trigger_handle
+ struct iio_poll_func *pf = private;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct si1145_data *data = iio_priv(indio_dev);
+- /*
+- * Maximum buffer size:
+- * 6*2 bytes channels data + 4 bytes alignment +
+- * 8 bytes timestamp
+- */
+- u8 buffer[24];
+ int i, j = 0;
+ int ret;
+ u8 irq_status = 0;
+@@ -482,7 +485,7 @@ static irqreturn_t si1145_trigger_handle
+
+ ret = i2c_smbus_read_i2c_block_data_or_emulated(
+ data->client, indio_dev->channels[i].address,
+- sizeof(u16) * run, &buffer[j]);
++ sizeof(u16) * run, &data->buffer[j]);
+ if (ret < 0)
+ goto done;
+ j += run * sizeof(u16);
+@@ -497,7 +500,7 @@ static irqreturn_t si1145_trigger_handle
+ goto done;
+ }
+
+- iio_push_to_buffers_with_timestamp(indio_dev, buffer,
++ iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
+ iio_get_time_ns(indio_dev));
+
+ done:
--- /dev/null
+From ff5c89d44453e7ad99502b04bf798a3fc32c758b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
+Date: Fri, 18 Sep 2020 00:32:58 +0200
+Subject: leds: bcm6328, bcm6358: use devres LED registering function
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Behún <marek.behun@nic.cz>
+
+commit ff5c89d44453e7ad99502b04bf798a3fc32c758b upstream.
+
+These two drivers do not provide remove method and use devres for
+allocation of other resources, yet they use led_classdev_register
+instead of the devres variant, devm_led_classdev_register.
+
+Fix this.
+
+Signed-off-by: Marek Behún <marek.behun@nic.cz>
+Cc: Álvaro Fernández Rojas <noltari@gmail.com>
+Cc: Kevin Cernekee <cernekee@gmail.com>
+Cc: Jaedon Shin <jaedon.shin@gmail.com>
+Signed-off-by: Pavel Machek <pavel@ucw.cz>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/leds/leds-bcm6328.c | 2 +-
+ drivers/leds/leds-bcm6358.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/leds/leds-bcm6328.c
++++ b/drivers/leds/leds-bcm6328.c
+@@ -336,7 +336,7 @@ static int bcm6328_led(struct device *de
+ led->cdev.brightness_set = bcm6328_led_set;
+ led->cdev.blink_set = bcm6328_blink_set;
+
+- rc = led_classdev_register(dev, &led->cdev);
++ rc = devm_led_classdev_register(dev, &led->cdev);
+ if (rc < 0)
+ return rc;
+
+--- a/drivers/leds/leds-bcm6358.c
++++ b/drivers/leds/leds-bcm6358.c
+@@ -141,7 +141,7 @@ static int bcm6358_led(struct device *de
+
+ led->cdev.brightness_set = bcm6358_led_set;
+
+- rc = led_classdev_register(dev, &led->cdev);
++ rc = devm_led_classdev_register(dev, &led->cdev);
+ if (rc < 0)
+ return rc;
+
--- /dev/null
+From 247db73560bc3e5aef6db50c443c3c0db115bc93 Mon Sep 17 00:00:00 2001
+From: Ashish Sangwan <ashishsangwan2@gmail.com>
+Date: Mon, 5 Oct 2020 02:22:43 -0700
+Subject: NFS: fix nfs_path in case of a rename retry
+
+From: Ashish Sangwan <ashishsangwan2@gmail.com>
+
+commit 247db73560bc3e5aef6db50c443c3c0db115bc93 upstream.
+
+We are generating incorrect path in case of rename retry because
+we are restarting from wrong dentry. We should restart from the
+dentry which was received in the call to nfs_path.
+
+CC: stable@vger.kernel.org
+Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/namespace.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/fs/nfs/namespace.c
++++ b/fs/nfs/namespace.c
+@@ -30,9 +30,9 @@ int nfs_mountpoint_expiry_timeout = 500
+ /*
+ * nfs_path - reconstruct the path given an arbitrary dentry
+ * @base - used to return pointer to the end of devname part of path
+- * @dentry - pointer to dentry
++ * @dentry_in - pointer to dentry
+ * @buffer - result buffer
+- * @buflen - length of buffer
++ * @buflen_in - length of buffer
+ * @flags - options (see below)
+ *
+ * Helper function for constructing the server pathname
+@@ -47,15 +47,19 @@ int nfs_mountpoint_expiry_timeout = 500
+ * the original device (export) name
+ * (if unset, the original name is returned verbatim)
+ */
+-char *nfs_path(char **p, struct dentry *dentry, char *buffer, ssize_t buflen,
+- unsigned flags)
++char *nfs_path(char **p, struct dentry *dentry_in, char *buffer,
++ ssize_t buflen_in, unsigned flags)
+ {
+ char *end;
+ int namelen;
+ unsigned seq;
+ const char *base;
++ struct dentry *dentry;
++ ssize_t buflen;
+
+ rename_retry:
++ buflen = buflen_in;
++ dentry = dentry_in;
+ end = buffer+buflen;
+ *--end = '\0';
+ buflen--;
--- /dev/null
+From 6b3dccd48de8a4c650b01499a0b09d1e2279649e Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Thu, 1 Oct 2020 18:58:56 -0400
+Subject: NFSD: Add missing NFSv2 .pc_func methods
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 6b3dccd48de8a4c650b01499a0b09d1e2279649e upstream.
+
+There's no protection in nfsd_dispatch() against a NULL .pc_func
+helpers. A malicious NFS client can trigger a crash by invoking the
+unused/unsupported NFSv2 ROOT or WRITECACHE procedures.
+
+The current NFSD dispatcher does not support returning a void reply
+to a non-NULL procedure, so the reply to both of these is wrong, for
+the moment.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfsproc.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/fs/nfsd/nfsproc.c
++++ b/fs/nfsd/nfsproc.c
+@@ -118,6 +118,13 @@ done:
+ return nfsd_return_attrs(nfserr, resp);
+ }
+
++/* Obsolete, replaced by MNTPROC_MNT. */
++static __be32
++nfsd_proc_root(struct svc_rqst *rqstp)
++{
++ return nfs_ok;
++}
++
+ /*
+ * Look up a path name component
+ * Note: the dentry in the resp->fh may be negative if the file
+@@ -201,6 +208,13 @@ nfsd_proc_read(struct svc_rqst *rqstp)
+ return fh_getattr(&resp->fh, &resp->stat);
+ }
+
++/* Reserved */
++static __be32
++nfsd_proc_writecache(struct svc_rqst *rqstp)
++{
++ return nfs_ok;
++}
++
+ /*
+ * Write data to a file
+ * N.B. After this call resp->fh needs an fh_put
+@@ -605,6 +619,7 @@ static const struct svc_procedure nfsd_p
+ .pc_xdrressize = ST+AT,
+ },
+ [NFSPROC_ROOT] = {
++ .pc_func = nfsd_proc_root,
+ .pc_decode = nfssvc_decode_void,
+ .pc_encode = nfssvc_encode_void,
+ .pc_argsize = sizeof(struct nfsd_void),
+@@ -642,6 +657,7 @@ static const struct svc_procedure nfsd_p
+ .pc_xdrressize = ST+AT+1+NFSSVC_MAXBLKSIZE_V2/4,
+ },
+ [NFSPROC_WRITECACHE] = {
++ .pc_func = nfsd_proc_writecache,
+ .pc_decode = nfssvc_decode_void,
+ .pc_encode = nfssvc_encode_void,
+ .pc_argsize = sizeof(struct nfsd_void),
--- /dev/null
+From 8c39076c276be0b31982e44654e2c2357473258a Mon Sep 17 00:00:00 2001
+From: Olga Kornievskaia <kolga@netapp.com>
+Date: Fri, 16 Oct 2020 09:25:45 -0400
+Subject: NFSv4.2: support EXCHGID4_FLAG_SUPP_FENCE_OPS 4.2 EXCHANGE_ID flag
+
+From: Olga Kornievskaia <kolga@netapp.com>
+
+commit 8c39076c276be0b31982e44654e2c2357473258a upstream.
+
+RFC 7862 introduced a new flag that either client or server is
+allowed to set: EXCHGID4_FLAG_SUPP_FENCE_OPS.
+
+Client needs to update its bitmask to allow for this flag value.
+
+v2: changed minor version argument to unsigned int
+
+Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 9 ++++++---
+ include/uapi/linux/nfs4.h | 3 +++
+ 2 files changed, 9 insertions(+), 3 deletions(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -7283,9 +7283,11 @@ int nfs4_proc_secinfo(struct inode *dir,
+ * both PNFS and NON_PNFS flags set, and not having one of NON_PNFS, PNFS, or
+ * DS flags set.
+ */
+-static int nfs4_check_cl_exchange_flags(u32 flags)
++static int nfs4_check_cl_exchange_flags(u32 flags, u32 version)
+ {
+- if (flags & ~EXCHGID4_FLAG_MASK_R)
++ if (version >= 2 && (flags & ~EXCHGID4_2_FLAG_MASK_R))
++ goto out_inval;
++ else if (version < 2 && (flags & ~EXCHGID4_FLAG_MASK_R))
+ goto out_inval;
+ if ((flags & EXCHGID4_FLAG_USE_PNFS_MDS) &&
+ (flags & EXCHGID4_FLAG_USE_NON_PNFS))
+@@ -7680,7 +7682,8 @@ static int _nfs4_proc_exchange_id(struct
+ if (status != 0)
+ goto out;
+
+- status = nfs4_check_cl_exchange_flags(resp->flags);
++ status = nfs4_check_cl_exchange_flags(resp->flags,
++ clp->cl_mvops->minor_version);
+ if (status != 0)
+ goto out;
+
+--- a/include/uapi/linux/nfs4.h
++++ b/include/uapi/linux/nfs4.h
+@@ -136,6 +136,8 @@
+
+ #define EXCHGID4_FLAG_UPD_CONFIRMED_REC_A 0x40000000
+ #define EXCHGID4_FLAG_CONFIRMED_R 0x80000000
++
++#define EXCHGID4_FLAG_SUPP_FENCE_OPS 0x00000004
+ /*
+ * Since the validity of these bits depends on whether
+ * they're set in the argument or response, have separate
+@@ -143,6 +145,7 @@
+ */
+ #define EXCHGID4_FLAG_MASK_A 0x40070103
+ #define EXCHGID4_FLAG_MASK_R 0x80070103
++#define EXCHGID4_2_FLAG_MASK_R 0x80070107
+
+ #define SEQ4_STATUS_CB_PATH_DOWN 0x00000001
+ #define SEQ4_STATUS_CB_GSS_CONTEXTS_EXPIRING 0x00000002
--- /dev/null
+From aea948bb80b478ddc2448f7359d574387521a52d Mon Sep 17 00:00:00 2001
+From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
+Date: Tue, 6 Oct 2020 13:02:18 +0530
+Subject: powerpc/powernv/elog: Fix race while processing OPAL error log event.
+
+From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
+
+commit aea948bb80b478ddc2448f7359d574387521a52d upstream.
+
+Every error log reported by OPAL is exported to userspace through a
+sysfs interface and notified using kobject_uevent(). The userspace
+daemon (opal_errd) then reads the error log and acknowledges the error
+log is saved safely to disk. Once acknowledged the kernel removes the
+respective sysfs file entry causing respective resources to be
+released including kobject.
+
+However it's possible the userspace daemon may already be scanning
+elog entries when a new sysfs elog entry is created by the kernel.
+User daemon may read this new entry and ack it even before kernel can
+notify userspace about it through kobject_uevent() call. If that
+happens then we have a potential race between
+elog_ack_store->kobject_put() and kobject_uevent which can lead to
+use-after-free of a kernfs object resulting in a kernel crash. eg:
+
+ BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb
+ Faulting instruction address: 0xc0000000008ff2a0
+ Oops: Kernel access of bad area, sig: 11 [#1]
+ LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
+ CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty #363
+ ...
+ NIP kobject_uevent_env+0xa0/0x910
+ LR elog_event+0x1f4/0x2d0
+ Call Trace:
+ 0x5deadbeef0000122 (unreliable)
+ elog_event+0x1f4/0x2d0
+ irq_thread_fn+0x4c/0xc0
+ irq_thread+0x1c0/0x2b0
+ kthread+0x1c4/0x1d0
+ ret_from_kernel_thread+0x5c/0x6c
+
+This patch fixes this race by protecting the sysfs file
+creation/notification by holding a reference count on kobject until we
+safely send kobject_uevent().
+
+The function create_elog_obj() returns the elog object which if used
+by caller function will end up in use-after-free problem again.
+However, the return value of create_elog_obj() function isn't being
+used today and there is no need as well. Hence change it to return
+void to make this fix complete.
+
+Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs")
+Cc: stable@vger.kernel.org # v3.15+
+Reported-by: Oliver O'Halloran <oohall@gmail.com>
+Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
+Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
+[mpe: Rework the logic to use a single return, reword comments, add oops]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/opal-elog.c | 33 ++++++++++++++++++++++-------
+ 1 file changed, 26 insertions(+), 7 deletions(-)
+
+--- a/arch/powerpc/platforms/powernv/opal-elog.c
++++ b/arch/powerpc/platforms/powernv/opal-elog.c
+@@ -183,14 +183,14 @@ static ssize_t raw_attr_read(struct file
+ return count;
+ }
+
+-static struct elog_obj *create_elog_obj(uint64_t id, size_t size, uint64_t type)
++static void create_elog_obj(uint64_t id, size_t size, uint64_t type)
+ {
+ struct elog_obj *elog;
+ int rc;
+
+ elog = kzalloc(sizeof(*elog), GFP_KERNEL);
+ if (!elog)
+- return NULL;
++ return;
+
+ elog->kobj.kset = elog_kset;
+
+@@ -223,18 +223,37 @@ static struct elog_obj *create_elog_obj(
+ rc = kobject_add(&elog->kobj, NULL, "0x%llx", id);
+ if (rc) {
+ kobject_put(&elog->kobj);
+- return NULL;
++ return;
+ }
+
++ /*
++ * As soon as the sysfs file for this elog is created/activated there is
++ * a chance the opal_errd daemon (or any userspace) might read and
++ * acknowledge the elog before kobject_uevent() is called. If that
++ * happens then there is a potential race between
++ * elog_ack_store->kobject_put() and kobject_uevent() which leads to a
++ * use-after-free of a kernfs object resulting in a kernel crash.
++ *
++ * To avoid that, we need to take a reference on behalf of the bin file,
++ * so that our reference remains valid while we call kobject_uevent().
++ * We then drop our reference before exiting the function, leaving the
++ * bin file to drop the last reference (if it hasn't already).
++ */
++
++ /* Take a reference for the bin file */
++ kobject_get(&elog->kobj);
+ rc = sysfs_create_bin_file(&elog->kobj, &elog->raw_attr);
+- if (rc) {
++ if (rc == 0) {
++ kobject_uevent(&elog->kobj, KOBJ_ADD);
++ } else {
++ /* Drop the reference taken for the bin file */
+ kobject_put(&elog->kobj);
+- return NULL;
+ }
+
+- kobject_uevent(&elog->kobj, KOBJ_ADD);
++ /* Drop our reference */
++ kobject_put(&elog->kobj);
+
+- return elog;
++ return;
+ }
+
+ static irqreturn_t elog_event(int irq, void *data)
--- /dev/null
+From bd59380c5ba4147dcbaad3e582b55ccfd120b764 Mon Sep 17 00:00:00 2001
+From: Andrew Donnellan <ajd@linux.ibm.com>
+Date: Thu, 20 Aug 2020 14:45:12 +1000
+Subject: powerpc/rtas: Restrict RTAS requests from userspace
+
+From: Andrew Donnellan <ajd@linux.ibm.com>
+
+commit bd59380c5ba4147dcbaad3e582b55ccfd120b764 upstream.
+
+A number of userspace utilities depend on making calls to RTAS to retrieve
+information and update various things.
+
+The existing API through which we expose RTAS to userspace exposes more
+RTAS functionality than we actually need, through the sys_rtas syscall,
+which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
+want with arbitrary arguments.
+
+Many RTAS calls take the address of a buffer as an argument, and it's up to
+the caller to specify the physical address of the buffer as an argument. We
+allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
+access, and then expose the physical address and size of this buffer in
+/proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
+poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
+the RTAS call.
+
+However, there's nothing stopping the caller from specifying whatever
+address they want in the RTAS call, and it's easy to construct a series of
+RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
+access).
+
+Additionally, there are some RTAS calls that do potentially dangerous
+things and for which there are no legitimate userspace use cases.
+
+In the past, this would not have been a particularly big deal as it was
+assumed that root could modify all system state freely, but with Secure
+Boot and lockdown we need to care about this.
+
+We can't fundamentally change the ABI at this point, however we can address
+this by implementing a filter that checks RTAS calls against a list
+of permitted calls and forces the caller to use addresses within the RMO
+buffer.
+
+The list is based off the list of calls that are used by the librtas
+userspace library, and has been tested with a number of existing userspace
+RTAS utilities. For compatibility with any applications we are not aware of
+that require other calls, the filter can be turned off at build time.
+
+Cc: stable@vger.kernel.org
+Reported-by: Daniel Axtens <dja@axtens.net>
+Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200820044512.7543-1-ajd@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/Kconfig | 13 +++
+ arch/powerpc/kernel/rtas.c | 153 +++++++++++++++++++++++++++++++++++++++++++++
+ 2 files changed, 166 insertions(+)
+
+--- a/arch/powerpc/Kconfig
++++ b/arch/powerpc/Kconfig
+@@ -1027,6 +1027,19 @@ config FSL_RIO
+
+ source "drivers/rapidio/Kconfig"
+
++config PPC_RTAS_FILTER
++ bool "Enable filtering of RTAS syscalls"
++ default y
++ depends on PPC_RTAS
++ help
++ The RTAS syscall API has security issues that could be used to
++ compromise system integrity. This option enforces restrictions on the
++ RTAS calls and arguments passed by userspace programs to mitigate
++ these issues.
++
++ Say Y unless you know what you are doing and the filter is causing
++ problems for you.
++
+ endmenu
+
+ config NONSTATIC_KERNEL
+--- a/arch/powerpc/kernel/rtas.c
++++ b/arch/powerpc/kernel/rtas.c
+@@ -1056,6 +1056,147 @@ struct pseries_errorlog *get_pseries_err
+ return NULL;
+ }
+
++#ifdef CONFIG_PPC_RTAS_FILTER
++
++/*
++ * The sys_rtas syscall, as originally designed, allows root to pass
++ * arbitrary physical addresses to RTAS calls. A number of RTAS calls
++ * can be abused to write to arbitrary memory and do other things that
++ * are potentially harmful to system integrity, and thus should only
++ * be used inside the kernel and not exposed to userspace.
++ *
++ * All known legitimate users of the sys_rtas syscall will only ever
++ * pass addresses that fall within the RMO buffer, and use a known
++ * subset of RTAS calls.
++ *
++ * Accordingly, we filter RTAS requests to check that the call is
++ * permitted, and that provided pointers fall within the RMO buffer.
++ * The rtas_filters list contains an entry for each permitted call,
++ * with the indexes of the parameters which are expected to contain
++ * addresses and sizes of buffers allocated inside the RMO buffer.
++ */
++struct rtas_filter {
++ const char *name;
++ int token;
++ /* Indexes into the args buffer, -1 if not used */
++ int buf_idx1;
++ int size_idx1;
++ int buf_idx2;
++ int size_idx2;
++
++ int fixed_size;
++};
++
++static struct rtas_filter rtas_filters[] __ro_after_init = {
++ { "ibm,activate-firmware", -1, -1, -1, -1, -1 },
++ { "ibm,configure-connector", -1, 0, -1, 1, -1, 4096 }, /* Special cased */
++ { "display-character", -1, -1, -1, -1, -1 },
++ { "ibm,display-message", -1, 0, -1, -1, -1 },
++ { "ibm,errinjct", -1, 2, -1, -1, -1, 1024 },
++ { "ibm,close-errinjct", -1, -1, -1, -1, -1 },
++ { "ibm,open-errinct", -1, -1, -1, -1, -1 },
++ { "ibm,get-config-addr-info2", -1, -1, -1, -1, -1 },
++ { "ibm,get-dynamic-sensor-state", -1, 1, -1, -1, -1 },
++ { "ibm,get-indices", -1, 2, 3, -1, -1 },
++ { "get-power-level", -1, -1, -1, -1, -1 },
++ { "get-sensor-state", -1, -1, -1, -1, -1 },
++ { "ibm,get-system-parameter", -1, 1, 2, -1, -1 },
++ { "get-time-of-day", -1, -1, -1, -1, -1 },
++ { "ibm,get-vpd", -1, 0, -1, 1, 2 },
++ { "ibm,lpar-perftools", -1, 2, 3, -1, -1 },
++ { "ibm,platform-dump", -1, 4, 5, -1, -1 },
++ { "ibm,read-slot-reset-state", -1, -1, -1, -1, -1 },
++ { "ibm,scan-log-dump", -1, 0, 1, -1, -1 },
++ { "ibm,set-dynamic-indicator", -1, 2, -1, -1, -1 },
++ { "ibm,set-eeh-option", -1, -1, -1, -1, -1 },
++ { "set-indicator", -1, -1, -1, -1, -1 },
++ { "set-power-level", -1, -1, -1, -1, -1 },
++ { "set-time-for-power-on", -1, -1, -1, -1, -1 },
++ { "ibm,set-system-parameter", -1, 1, -1, -1, -1 },
++ { "set-time-of-day", -1, -1, -1, -1, -1 },
++ { "ibm,suspend-me", -1, -1, -1, -1, -1 },
++ { "ibm,update-nodes", -1, 0, -1, -1, -1, 4096 },
++ { "ibm,update-properties", -1, 0, -1, -1, -1, 4096 },
++ { "ibm,physical-attestation", -1, 0, 1, -1, -1 },
++};
++
++static bool in_rmo_buf(u32 base, u32 end)
++{
++ return base >= rtas_rmo_buf &&
++ base < (rtas_rmo_buf + RTAS_RMOBUF_MAX) &&
++ base <= end &&
++ end >= rtas_rmo_buf &&
++ end < (rtas_rmo_buf + RTAS_RMOBUF_MAX);
++}
++
++static bool block_rtas_call(int token, int nargs,
++ struct rtas_args *args)
++{
++ int i;
++
++ for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
++ struct rtas_filter *f = &rtas_filters[i];
++ u32 base, size, end;
++
++ if (token != f->token)
++ continue;
++
++ if (f->buf_idx1 != -1) {
++ base = be32_to_cpu(args->args[f->buf_idx1]);
++ if (f->size_idx1 != -1)
++ size = be32_to_cpu(args->args[f->size_idx1]);
++ else if (f->fixed_size)
++ size = f->fixed_size;
++ else
++ size = 1;
++
++ end = base + size - 1;
++ if (!in_rmo_buf(base, end))
++ goto err;
++ }
++
++ if (f->buf_idx2 != -1) {
++ base = be32_to_cpu(args->args[f->buf_idx2]);
++ if (f->size_idx2 != -1)
++ size = be32_to_cpu(args->args[f->size_idx2]);
++ else if (f->fixed_size)
++ size = f->fixed_size;
++ else
++ size = 1;
++ end = base + size - 1;
++
++ /*
++ * Special case for ibm,configure-connector where the
++ * address can be 0
++ */
++ if (!strcmp(f->name, "ibm,configure-connector") &&
++ base == 0)
++ return false;
++
++ if (!in_rmo_buf(base, end))
++ goto err;
++ }
++
++ return false;
++ }
++
++err:
++ pr_err_ratelimited("sys_rtas: RTAS call blocked - exploit attempt?\n");
++ pr_err_ratelimited("sys_rtas: token=0x%x, nargs=%d (called by %s)\n",
++ token, nargs, current->comm);
++ return true;
++}
++
++#else
++
++static bool block_rtas_call(int token, int nargs,
++ struct rtas_args *args)
++{
++ return false;
++}
++
++#endif /* CONFIG_PPC_RTAS_FILTER */
++
+ /* We assume to be passed big endian arguments */
+ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
+ {
+@@ -1093,6 +1234,9 @@ asmlinkage int ppc_rtas(struct rtas_args
+ args.rets = &args.args[nargs];
+ memset(args.rets, 0, nret * sizeof(rtas_arg_t));
+
++ if (block_rtas_call(token, nargs, &args))
++ return -EINVAL;
++
+ /* Need to handle ibm,suspend_me call specially */
+ if (token == ibm_suspend_me_token) {
+
+@@ -1154,6 +1298,9 @@ void __init rtas_initialize(void)
+ unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
+ u32 base, size, entry;
+ int no_base, no_size, no_entry;
++#ifdef CONFIG_PPC_RTAS_FILTER
++ int i;
++#endif
+
+ /* Get RTAS dev node and fill up our "rtas" structure with infos
+ * about it.
+@@ -1189,6 +1336,12 @@ void __init rtas_initialize(void)
+ #ifdef CONFIG_RTAS_ERROR_LOGGING
+ rtas_last_error_token = rtas_token("rtas-last-error");
+ #endif
++
++#ifdef CONFIG_PPC_RTAS_FILTER
++ for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
++ rtas_filters[i].token = rtas_token(rtas_filters[i].name);
++ }
++#endif
+ }
+
+ int __init early_init_dt_scan_rtas(unsigned long node,
--- /dev/null
+From a02f6d42357acf6e5de6ffc728e6e77faf3ad217 Mon Sep 17 00:00:00 2001
+From: Joel Stanley <joel@jms.id.au>
+Date: Wed, 2 Sep 2020 09:30:11 +0930
+Subject: powerpc: Warn about use of smt_snooze_delay
+
+From: Joel Stanley <joel@jms.id.au>
+
+commit a02f6d42357acf6e5de6ffc728e6e77faf3ad217 upstream.
+
+It's not done anything for a long time. Save the percpu variable, and
+emit a warning to remind users to not expect it to do anything.
+
+This uses pr_warn_once instead of pr_warn_ratelimit as testing
+'ppc64_cpu --smt=off' on a 24 core / 4 SMT system showed the warning
+to be noisy, as the online/offline loop is slow.
+
+Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
+Cc: stable@vger.kernel.org # v3.14
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200902000012.3440389-1-joel@jms.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/sysfs.c | 42 +++++++++++++++++-------------------------
+ 1 file changed, 17 insertions(+), 25 deletions(-)
+
+--- a/arch/powerpc/kernel/sysfs.c
++++ b/arch/powerpc/kernel/sysfs.c
+@@ -28,29 +28,27 @@
+
+ static DEFINE_PER_CPU(struct cpu, cpu_devices);
+
+-/*
+- * SMT snooze delay stuff, 64-bit only for now
+- */
+-
+ #ifdef CONFIG_PPC64
+
+-/* Time in microseconds we delay before sleeping in the idle loop */
+-static DEFINE_PER_CPU(long, smt_snooze_delay) = { 100 };
++/*
++ * Snooze delay has not been hooked up since 3fa8cad82b94 ("powerpc/pseries/cpuidle:
++ * smt-snooze-delay cleanup.") and has been broken even longer. As was foretold in
++ * 2014:
++ *
++ * "ppc64_util currently utilises it. Once we fix ppc64_util, propose to clean
++ * up the kernel code."
++ *
++ * powerpc-utils stopped using it as of 1.3.8. At some point in the future this
++ * code should be removed.
++ */
+
+ static ssize_t store_smt_snooze_delay(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+ {
+- struct cpu *cpu = container_of(dev, struct cpu, dev);
+- ssize_t ret;
+- long snooze;
+-
+- ret = sscanf(buf, "%ld", &snooze);
+- if (ret != 1)
+- return -EINVAL;
+-
+- per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
++ pr_warn_once("%s (%d) stored to unsupported smt_snooze_delay, which has no effect.\n",
++ current->comm, current->pid);
+ return count;
+ }
+
+@@ -58,9 +56,9 @@ static ssize_t show_smt_snooze_delay(str
+ struct device_attribute *attr,
+ char *buf)
+ {
+- struct cpu *cpu = container_of(dev, struct cpu, dev);
+-
+- return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
++ pr_warn_once("%s (%d) read from unsupported smt_snooze_delay\n",
++ current->comm, current->pid);
++ return sprintf(buf, "100\n");
+ }
+
+ static DEVICE_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
+@@ -68,16 +66,10 @@ static DEVICE_ATTR(smt_snooze_delay, 064
+
+ static int __init setup_smt_snooze_delay(char *str)
+ {
+- unsigned int cpu;
+- long snooze;
+-
+ if (!cpu_has_feature(CPU_FTR_SMT))
+ return 1;
+
+- snooze = simple_strtol(str, NULL, 10);
+- for_each_possible_cpu(cpu)
+- per_cpu(smt_snooze_delay, cpu) = snooze;
+-
++ pr_warn("smt-snooze-delay command line option has no effect\n");
+ return 1;
+ }
+ __setup("smt-snooze-delay=", setup_smt_snooze_delay);
--- /dev/null
+From b3bd02495cb339124f13135d51940cf48d83e5cb Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@linux.ibm.com>
+Date: Tue, 15 Sep 2020 08:53:50 +0200
+Subject: s390/stp: add locking to sysfs functions
+
+From: Sven Schnelle <svens@linux.ibm.com>
+
+commit b3bd02495cb339124f13135d51940cf48d83e5cb upstream.
+
+The sysfs function might race with stp_work_fn. To prevent that,
+add the required locking. Another issue is that the sysfs functions
+are checking the stp_online flag, but this flag just holds the user
+setting whether STP is enabled. Add a flag to clock_sync_flag whether
+stp_info holds valid data and use that instead.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
+Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/time.c | 118 ++++++++++++++++++++++++++++++++++--------------
+ 1 file changed, 85 insertions(+), 33 deletions(-)
+
+--- a/arch/s390/kernel/time.c
++++ b/arch/s390/kernel/time.c
+@@ -347,8 +347,9 @@ static DEFINE_PER_CPU(atomic_t, clock_sy
+ static DEFINE_MUTEX(clock_sync_mutex);
+ static unsigned long clock_sync_flags;
+
+-#define CLOCK_SYNC_HAS_STP 0
+-#define CLOCK_SYNC_STP 1
++#define CLOCK_SYNC_HAS_STP 0
++#define CLOCK_SYNC_STP 1
++#define CLOCK_SYNC_STPINFO_VALID 2
+
+ /*
+ * The get_clock function for the physical clock. It will get the current
+@@ -585,6 +586,22 @@ void stp_queue_work(void)
+ queue_work(time_sync_wq, &stp_work);
+ }
+
++static int __store_stpinfo(void)
++{
++ int rc = chsc_sstpi(stp_page, &stp_info, sizeof(struct stp_sstpi));
++
++ if (rc)
++ clear_bit(CLOCK_SYNC_STPINFO_VALID, &clock_sync_flags);
++ else
++ set_bit(CLOCK_SYNC_STPINFO_VALID, &clock_sync_flags);
++ return rc;
++}
++
++static int stpinfo_valid(void)
++{
++ return stp_online && test_bit(CLOCK_SYNC_STPINFO_VALID, &clock_sync_flags);
++}
++
+ static int stp_sync_clock(void *data)
+ {
+ struct clock_sync_data *sync = data;
+@@ -606,8 +623,7 @@ static int stp_sync_clock(void *data)
+ if (rc == 0) {
+ sync->clock_delta = clock_delta;
+ clock_sync_global(clock_delta);
+- rc = chsc_sstpi(stp_page, &stp_info,
+- sizeof(struct stp_sstpi));
++ rc = __store_stpinfo();
+ if (rc == 0 && stp_info.tmd != 2)
+ rc = -EAGAIN;
+ }
+@@ -652,7 +668,7 @@ static void stp_work_fn(struct work_stru
+ if (rc)
+ goto out_unlock;
+
+- rc = chsc_sstpi(stp_page, &stp_info, sizeof(struct stp_sstpi));
++ rc = __store_stpinfo();
+ if (rc || stp_info.c == 0)
+ goto out_unlock;
+
+@@ -689,10 +705,14 @@ static ssize_t stp_ctn_id_show(struct de
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online)
+- return -ENODATA;
+- return sprintf(buf, "%016llx\n",
+- *(unsigned long long *) stp_info.ctnid);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid())
++ ret = sprintf(buf, "%016llx\n",
++ *(unsigned long long *) stp_info.ctnid);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(ctn_id, 0400, stp_ctn_id_show, NULL);
+@@ -701,9 +721,13 @@ static ssize_t stp_ctn_type_show(struct
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online)
+- return -ENODATA;
+- return sprintf(buf, "%i\n", stp_info.ctn);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid())
++ ret = sprintf(buf, "%i\n", stp_info.ctn);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(ctn_type, 0400, stp_ctn_type_show, NULL);
+@@ -712,9 +736,13 @@ static ssize_t stp_dst_offset_show(struc
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online || !(stp_info.vbits & 0x2000))
+- return -ENODATA;
+- return sprintf(buf, "%i\n", (int)(s16) stp_info.dsto);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid() && (stp_info.vbits & 0x2000))
++ ret = sprintf(buf, "%i\n", (int)(s16) stp_info.dsto);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(dst_offset, 0400, stp_dst_offset_show, NULL);
+@@ -723,9 +751,13 @@ static ssize_t stp_leap_seconds_show(str
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online || !(stp_info.vbits & 0x8000))
+- return -ENODATA;
+- return sprintf(buf, "%i\n", (int)(s16) stp_info.leaps);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid() && (stp_info.vbits & 0x8000))
++ ret = sprintf(buf, "%i\n", (int)(s16) stp_info.leaps);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(leap_seconds, 0400, stp_leap_seconds_show, NULL);
+@@ -734,9 +766,13 @@ static ssize_t stp_stratum_show(struct d
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online)
+- return -ENODATA;
+- return sprintf(buf, "%i\n", (int)(s16) stp_info.stratum);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid())
++ ret = sprintf(buf, "%i\n", (int)(s16) stp_info.stratum);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(stratum, 0400, stp_stratum_show, NULL);
+@@ -745,9 +781,13 @@ static ssize_t stp_time_offset_show(stru
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online || !(stp_info.vbits & 0x0800))
+- return -ENODATA;
+- return sprintf(buf, "%i\n", (int) stp_info.tto);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid() && (stp_info.vbits & 0x0800))
++ ret = sprintf(buf, "%i\n", (int) stp_info.tto);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(time_offset, 0400, stp_time_offset_show, NULL);
+@@ -756,9 +796,13 @@ static ssize_t stp_time_zone_offset_show
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online || !(stp_info.vbits & 0x4000))
+- return -ENODATA;
+- return sprintf(buf, "%i\n", (int)(s16) stp_info.tzo);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid() && (stp_info.vbits & 0x4000))
++ ret = sprintf(buf, "%i\n", (int)(s16) stp_info.tzo);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(time_zone_offset, 0400,
+@@ -768,9 +812,13 @@ static ssize_t stp_timing_mode_show(stru
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online)
+- return -ENODATA;
+- return sprintf(buf, "%i\n", stp_info.tmd);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid())
++ ret = sprintf(buf, "%i\n", stp_info.tmd);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(timing_mode, 0400, stp_timing_mode_show, NULL);
+@@ -779,9 +827,13 @@ static ssize_t stp_timing_state_show(str
+ struct device_attribute *attr,
+ char *buf)
+ {
+- if (!stp_online)
+- return -ENODATA;
+- return sprintf(buf, "%i\n", stp_info.tst);
++ ssize_t ret = -ENODATA;
++
++ mutex_lock(&stp_work_mutex);
++ if (stpinfo_valid())
++ ret = sprintf(buf, "%i\n", stp_info.tst);
++ mutex_unlock(&stp_work_mutex);
++ return ret;
+ }
+
+ static DEVICE_ATTR(timing_state, 0400, stp_timing_state_show, NULL);
--- /dev/null
+From 2f4843b172c2c0360ee7792ad98025fae7baefde Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Thu, 22 Oct 2020 11:00:05 +0200
+Subject: scsi: mptfusion: Fix null pointer dereferences in mptscsih_remove()
+
+From: Helge Deller <deller@gmx.de>
+
+commit 2f4843b172c2c0360ee7792ad98025fae7baefde upstream.
+
+The mptscsih_remove() function triggers a kernel oops if the Scsi_Host
+pointer (ioc->sh) is NULL, as can be seen in this syslog:
+
+ ioc0: LSI53C1030 B2: Capabilities={Initiator,Target}
+ Begin: Waiting for root file system ...
+ scsi host2: error handler thread failed to spawn, error = -4
+ mptspi: ioc0: WARNING - Unable to register controller with SCSI subsystem
+ Backtrace:
+ [<000000001045b7cc>] mptspi_probe+0x248/0x3d0 [mptspi]
+ [<0000000040946470>] pci_device_probe+0x1ac/0x2d8
+ [<0000000040add668>] really_probe+0x1bc/0x988
+ [<0000000040ade704>] driver_probe_device+0x160/0x218
+ [<0000000040adee24>] device_driver_attach+0x160/0x188
+ [<0000000040adef90>] __driver_attach+0x144/0x320
+ [<0000000040ad7c78>] bus_for_each_dev+0xd4/0x158
+ [<0000000040adc138>] driver_attach+0x4c/0x80
+ [<0000000040adb3ec>] bus_add_driver+0x3e0/0x498
+ [<0000000040ae0130>] driver_register+0xf4/0x298
+ [<00000000409450c4>] __pci_register_driver+0x78/0xa8
+ [<000000000007d248>] mptspi_init+0x18c/0x1c4 [mptspi]
+
+This patch adds the necessary NULL-pointer checks. Successfully tested on
+a HP C8000 parisc workstation with buggy SCSI drives.
+
+Link: https://lore.kernel.org/r/20201022090005.GA9000@ls3530.fritz.box
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/message/fusion/mptscsih.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/message/fusion/mptscsih.c
++++ b/drivers/message/fusion/mptscsih.c
+@@ -1174,8 +1174,10 @@ mptscsih_remove(struct pci_dev *pdev)
+ MPT_SCSI_HOST *hd;
+ int sz1;
+
+- if((hd = shost_priv(host)) == NULL)
+- return;
++ if (host == NULL)
++ hd = NULL;
++ else
++ hd = shost_priv(host);
+
+ mptscsih_shutdown(pdev);
+
+@@ -1191,14 +1193,15 @@ mptscsih_remove(struct pci_dev *pdev)
+ "Free'd ScsiLookup (%d) memory\n",
+ ioc->name, sz1));
+
+- kfree(hd->info_kbuf);
++ if (hd)
++ kfree(hd->info_kbuf);
+
+ /* NULL the Scsi_Host pointer
+ */
+ ioc->sh = NULL;
+
+- scsi_host_put(host);
+-
++ if (host)
++ scsi_host_put(host);
+ mpt_detach(pdev);
+
+ }
md-raid5-fix-oops-during-stripe-resizing.patch
perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch
perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch
+leds-bcm6328-bcm6358-use-devres-led-registering-function.patch
+fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch
+nfs-fix-nfs_path-in-case-of-a-rename-retry.patch
+acpi-extlog-check-for-rdmsr-failure.patch
+acpi-video-use-acpi-backlight-for-hp-635-notebook.patch
+acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch
+acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch
+w1-mxc_w1-fix-timeout-resolution-problem-leading-to-bus-error.patch
+scsi-mptfusion-fix-null-pointer-dereferences-in-mptscsih_remove.patch
+btrfs-reschedule-if-necessary-when-logging-directory-items.patch
+btrfs-send-recompute-reference-path-after-orphanization-of-a-directory.patch
+btrfs-use-kvzalloc-to-allocate-clone_roots-in-btrfs_ioctl_send.patch
+btrfs-cleanup-cow-block-on-error.patch
+btrfs-fix-use-after-free-on-readahead-extent-after-failure-to-create-it.patch
+usb-dwc3-ep0-fix-zlp-for-out-ep0-requests.patch
+usb-dwc3-core-add-phy-cleanup-for-probe-error-handling.patch
+usb-dwc3-core-don-t-trigger-runtime-pm-when-remove-driver.patch
+usb-cdc-acm-fix-cooldown-mechanism.patch
+usb-host-fsl-mph-dr-of-check-return-of-dma_set_mask.patch
+drm-i915-force-vt-d-workarounds-when-running-as-a-guest-os.patch
+vt-keyboard-simplify-vt_kdgkbsent.patch
+vt-keyboard-extend-func_buf_lock-to-readers.patch
+dmaengine-dma-jz4780-fix-race-in-jz4780_dma_tx_status.patch
+iio-light-si1145-fix-timestamp-alignment-and-prevent-data-leak.patch
+iio-adc-ti-adc0832-fix-alignment-issue-with-timestamp.patch
+iio-adc-ti-adc12138-fix-alignment-issue-with-timestamp.patch
+iio-gyro-itg3200-fix-timestamp-alignment-and-prevent-data-leak.patch
+s390-stp-add-locking-to-sysfs-functions.patch
+powerpc-rtas-restrict-rtas-requests-from-userspace.patch
+powerpc-warn-about-use-of-smt_snooze_delay.patch
+powerpc-powernv-elog-fix-race-while-processing-opal-error-log-event.patch
+nfsv4.2-support-exchgid4_flag_supp_fence_ops-4.2-exchange_id-flag.patch
+nfsd-add-missing-nfsv2-.pc_func-methods.patch
+ubifs-dent-fix-some-potential-memory-leaks-while-iterating-entries.patch
--- /dev/null
+From 58f6e78a65f1fcbf732f60a7478ccc99873ff3ba Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+Date: Mon, 1 Jun 2020 17:10:37 +0800
+Subject: ubifs: dent: Fix some potential memory leaks while iterating entries
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+commit 58f6e78a65f1fcbf732f60a7478ccc99873ff3ba upstream.
+
+Fix some potential memory leaks in error handling branches while
+iterating dent entries. For example, function dbg_check_dir()
+forgets to free pdent if it exists.
+
+Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Cc: <stable@vger.kernel.org>
+Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/debug.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ubifs/debug.c
++++ b/fs/ubifs/debug.c
+@@ -1129,6 +1129,7 @@ int dbg_check_dir(struct ubifs_info *c,
+ err = PTR_ERR(dent);
+ if (err == -ENOENT)
+ break;
++ kfree(pdent);
+ return err;
+ }
+
--- /dev/null
+From 38203b8385bf6283537162bde7d499f830964711 Mon Sep 17 00:00:00 2001
+From: Jerome Brunet <jbrunet@baylibre.com>
+Date: Mon, 19 Oct 2020 19:07:02 +0200
+Subject: usb: cdc-acm: fix cooldown mechanism
+
+From: Jerome Brunet <jbrunet@baylibre.com>
+
+commit 38203b8385bf6283537162bde7d499f830964711 upstream.
+
+Commit a4e7279cd1d1 ("cdc-acm: introduce a cool down") is causing
+regression if there is some USB error, such as -EPROTO.
+
+This has been reported on some samples of the Odroid-N2 using the Combee II
+Zibgee USB dongle.
+
+> struct acm *acm = container_of(work, struct acm, work)
+
+is incorrect in case of a delayed work and causes warnings, usually from
+the workqueue:
+
+> WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:1474 __queue_work+0x480/0x528.
+
+When this happens, USB eventually stops working completely after a while.
+Also the ACM_ERROR_DELAY bit is never set, so the cooldown mechanism
+previously introduced cannot be triggered and acm_submit_read_urb() is
+never called.
+
+This changes makes the cdc-acm driver use a single delayed work, fixing the
+pointer arithmetic in acm_softint() and set the ACM_ERROR_DELAY when the
+cooldown mechanism appear to be needed.
+
+Fixes: a4e7279cd1d1 ("cdc-acm: introduce a cool down")
+Cc: Oliver Neukum <oneukum@suse.com>
+Reported-by: Pascal Vizeli <pascal.vizeli@nabucasa.com>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Link: https://lore.kernel.org/r/20201019170702.150534-1-jbrunet@baylibre.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-acm.c | 12 +++++-------
+ drivers/usb/class/cdc-acm.h | 3 +--
+ 2 files changed, 6 insertions(+), 9 deletions(-)
+
+--- a/drivers/usb/class/cdc-acm.c
++++ b/drivers/usb/class/cdc-acm.c
+@@ -520,6 +520,7 @@ static void acm_read_bulk_callback(struc
+ "%s - cooling babbling device\n", __func__);
+ usb_mark_last_busy(acm->dev);
+ set_bit(rb->index, &acm->urbs_in_error_delay);
++ set_bit(ACM_ERROR_DELAY, &acm->flags);
+ cooldown = true;
+ break;
+ default:
+@@ -545,7 +546,7 @@ static void acm_read_bulk_callback(struc
+
+ if (stopped || stalled || cooldown) {
+ if (stalled)
+- schedule_work(&acm->work);
++ schedule_delayed_work(&acm->dwork, 0);
+ else if (cooldown)
+ schedule_delayed_work(&acm->dwork, HZ / 2);
+ return;
+@@ -580,13 +581,13 @@ static void acm_write_bulk(struct urb *u
+ acm_write_done(acm, wb);
+ spin_unlock_irqrestore(&acm->write_lock, flags);
+ set_bit(EVENT_TTY_WAKEUP, &acm->flags);
+- schedule_work(&acm->work);
++ schedule_delayed_work(&acm->dwork, 0);
+ }
+
+ static void acm_softint(struct work_struct *work)
+ {
+ int i;
+- struct acm *acm = container_of(work, struct acm, work);
++ struct acm *acm = container_of(work, struct acm, dwork.work);
+
+ if (test_bit(EVENT_RX_STALL, &acm->flags)) {
+ smp_mb(); /* against acm_suspend() */
+@@ -602,7 +603,7 @@ static void acm_softint(struct work_stru
+ if (test_and_clear_bit(ACM_ERROR_DELAY, &acm->flags)) {
+ for (i = 0; i < acm->rx_buflimit; i++)
+ if (test_and_clear_bit(i, &acm->urbs_in_error_delay))
+- acm_submit_read_urb(acm, i, GFP_NOIO);
++ acm_submit_read_urb(acm, i, GFP_KERNEL);
+ }
+
+ if (test_and_clear_bit(EVENT_TTY_WAKEUP, &acm->flags))
+@@ -1405,7 +1406,6 @@ made_compressed_probe:
+ acm->ctrlsize = ctrlsize;
+ acm->readsize = readsize;
+ acm->rx_buflimit = num_rx_buf;
+- INIT_WORK(&acm->work, acm_softint);
+ INIT_DELAYED_WORK(&acm->dwork, acm_softint);
+ init_waitqueue_head(&acm->wioctl);
+ spin_lock_init(&acm->write_lock);
+@@ -1619,7 +1619,6 @@ static void acm_disconnect(struct usb_in
+ }
+
+ acm_kill_urbs(acm);
+- cancel_work_sync(&acm->work);
+ cancel_delayed_work_sync(&acm->dwork);
+
+ tty_unregister_device(acm_tty_driver, acm->minor);
+@@ -1662,7 +1661,6 @@ static int acm_suspend(struct usb_interf
+ return 0;
+
+ acm_kill_urbs(acm);
+- cancel_work_sync(&acm->work);
+ cancel_delayed_work_sync(&acm->dwork);
+ acm->urbs_in_error_delay = 0;
+
+--- a/drivers/usb/class/cdc-acm.h
++++ b/drivers/usb/class/cdc-acm.h
+@@ -111,8 +111,7 @@ struct acm {
+ # define ACM_ERROR_DELAY 3
+ unsigned long urbs_in_error_delay; /* these need to be restarted after a delay */
+ struct usb_cdc_line_coding line; /* bits, stop, parity */
+- struct work_struct work; /* work queue entry for various purposes*/
+- struct delayed_work dwork; /* for cool downs needed in error recovery */
++ struct delayed_work dwork; /* work queue entry for various purposes */
+ unsigned int ctrlin; /* input control lines (DCD, DSR, RI, break, overruns) */
+ unsigned int ctrlout; /* output control lines (DTR, RTS) */
+ struct async_icount iocount; /* counters for control line changes */
--- /dev/null
+From 03c1fd622f72c7624c81b64fdba4a567ae5ee9cb Mon Sep 17 00:00:00 2001
+From: Li Jun <jun.li@nxp.com>
+Date: Tue, 28 Jul 2020 20:42:41 +0800
+Subject: usb: dwc3: core: add phy cleanup for probe error handling
+
+From: Li Jun <jun.li@nxp.com>
+
+commit 03c1fd622f72c7624c81b64fdba4a567ae5ee9cb upstream.
+
+Add the phy cleanup if dwc3 mode init fail, which is the missing part of
+de-init for dwc3 core init.
+
+Fixes: c499ff71ff2a ("usb: dwc3: core: re-factor init and exit paths")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Li Jun <jun.li@nxp.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/core.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -1287,6 +1287,17 @@ static int dwc3_probe(struct platform_de
+
+ err5:
+ dwc3_event_buffers_cleanup(dwc);
++
++ usb_phy_shutdown(dwc->usb2_phy);
++ usb_phy_shutdown(dwc->usb3_phy);
++ phy_exit(dwc->usb2_generic_phy);
++ phy_exit(dwc->usb3_generic_phy);
++
++ usb_phy_set_suspend(dwc->usb2_phy, 1);
++ usb_phy_set_suspend(dwc->usb3_phy, 1);
++ phy_power_off(dwc->usb2_generic_phy);
++ phy_power_off(dwc->usb3_generic_phy);
++
+ dwc3_ulpi_exit(dwc);
+
+ err4:
--- /dev/null
+From 266d0493900ac5d6a21cdbe6b1624ed2da94d47a Mon Sep 17 00:00:00 2001
+From: Li Jun <jun.li@nxp.com>
+Date: Tue, 28 Jul 2020 20:42:40 +0800
+Subject: usb: dwc3: core: don't trigger runtime pm when remove driver
+
+From: Li Jun <jun.li@nxp.com>
+
+commit 266d0493900ac5d6a21cdbe6b1624ed2da94d47a upstream.
+
+No need to trigger runtime pm in driver removal, otherwise if user
+disable auto suspend via sys file, runtime suspend may be entered,
+which will call dwc3_core_exit() again and there will be clock disable
+not balance warning:
+
+[ 2026.820154] xhci-hcd xhci-hcd.0.auto: remove, state 4
+[ 2026.825268] usb usb2: USB disconnect, device number 1
+[ 2026.831017] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
+[ 2026.836806] xhci-hcd xhci-hcd.0.auto: remove, state 4
+[ 2026.842029] usb usb1: USB disconnect, device number 1
+[ 2026.848029] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
+[ 2026.865889] ------------[ cut here ]------------
+[ 2026.870506] usb2_ctrl_root_clk already disabled
+[ 2026.875082] WARNING: CPU: 0 PID: 731 at drivers/clk/clk.c:958
+clk_core_disable+0xa0/0xa8
+[ 2026.883170] Modules linked in: dwc3(-) phy_fsl_imx8mq_usb [last
+unloaded: dwc3]
+[ 2026.890488] CPU: 0 PID: 731 Comm: rmmod Not tainted
+5.8.0-rc7-00280-g9d08cca-dirty #245
+[ 2026.898489] Hardware name: NXP i.MX8MQ EVK (DT)
+[ 2026.903020] pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--)
+[ 2026.908594] pc : clk_core_disable+0xa0/0xa8
+[ 2026.912777] lr : clk_core_disable+0xa0/0xa8
+[ 2026.916958] sp : ffff8000121b39a0
+[ 2026.920271] x29: ffff8000121b39a0 x28: ffff0000b11f3700
+[ 2026.925583] x27: 0000000000000000 x26: ffff0000b539c700
+[ 2026.930895] x25: 000001d7e44e1232 x24: ffff0000b76fa800
+[ 2026.936208] x23: ffff0000b76fa6f8 x22: ffff800008d01040
+[ 2026.941520] x21: ffff0000b539ce00 x20: ffff0000b7105000
+[ 2026.946832] x19: ffff0000b7105000 x18: 0000000000000010
+[ 2026.952144] x17: 0000000000000001 x16: 0000000000000000
+[ 2026.957456] x15: ffff0000b11f3b70 x14: ffffffffffffffff
+[ 2026.962768] x13: ffff8000921b36f7 x12: ffff8000121b36ff
+[ 2026.968080] x11: ffff8000119e1000 x10: ffff800011bf26d0
+[ 2026.973392] x9 : 0000000000000000 x8 : ffff800011bf3000
+[ 2026.978704] x7 : ffff800010695d68 x6 : 0000000000000252
+[ 2026.984016] x5 : ffff0000bb9881f0 x4 : 0000000000000000
+[ 2026.989327] x3 : 0000000000000027 x2 : 0000000000000023
+[ 2026.994639] x1 : ac2fa471aa7cab00 x0 : 0000000000000000
+[ 2026.999951] Call trace:
+[ 2027.002401] clk_core_disable+0xa0/0xa8
+[ 2027.006238] clk_core_disable_lock+0x20/0x38
+[ 2027.010508] clk_disable+0x1c/0x28
+[ 2027.013911] clk_bulk_disable+0x34/0x50
+[ 2027.017758] dwc3_core_exit+0xec/0x110 [dwc3]
+[ 2027.022122] dwc3_suspend_common+0x84/0x188 [dwc3]
+[ 2027.026919] dwc3_runtime_suspend+0x74/0x9c [dwc3]
+[ 2027.031712] pm_generic_runtime_suspend+0x28/0x40
+[ 2027.036419] genpd_runtime_suspend+0xa0/0x258
+[ 2027.040777] __rpm_callback+0x88/0x140
+[ 2027.044526] rpm_callback+0x20/0x80
+[ 2027.048015] rpm_suspend+0xd0/0x418
+[ 2027.051503] __pm_runtime_suspend+0x58/0xa0
+[ 2027.055693] dwc3_runtime_idle+0x7c/0x90 [dwc3]
+[ 2027.060224] __rpm_callback+0x88/0x140
+[ 2027.063973] rpm_idle+0x78/0x150
+[ 2027.067201] __pm_runtime_idle+0x58/0xa0
+[ 2027.071130] dwc3_remove+0x64/0xc0 [dwc3]
+[ 2027.075140] platform_drv_remove+0x28/0x48
+[ 2027.079239] device_release_driver_internal+0xf4/0x1c0
+[ 2027.084377] driver_detach+0x4c/0xd8
+[ 2027.087954] bus_remove_driver+0x54/0xa8
+[ 2027.091877] driver_unregister+0x2c/0x58
+[ 2027.095799] platform_driver_unregister+0x10/0x18
+[ 2027.100509] dwc3_driver_exit+0x14/0x1408 [dwc3]
+[ 2027.105129] __arm64_sys_delete_module+0x178/0x218
+[ 2027.109922] el0_svc_common.constprop.0+0x68/0x160
+[ 2027.114714] do_el0_svc+0x20/0x80
+[ 2027.118031] el0_sync_handler+0x88/0x190
+[ 2027.121953] el0_sync+0x140/0x180
+[ 2027.125267] ---[ end trace 027f4f8189958f1f ]---
+[ 2027.129976] ------------[ cut here ]------------
+
+Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Li Jun <jun.li@nxp.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -1343,9 +1343,9 @@ static int dwc3_remove(struct platform_d
+ dwc3_core_exit(dwc);
+ dwc3_ulpi_exit(dwc);
+
+- pm_runtime_put_sync(&pdev->dev);
+- pm_runtime_allow(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
++ pm_runtime_put_noidle(&pdev->dev);
++ pm_runtime_set_suspended(&pdev->dev);
+
+ dwc3_free_event_buffers(dwc);
+ dwc3_free_scratch_buffers(dwc);
--- /dev/null
+From 66706077dc89c66a4777a4c6298273816afb848c Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Thu, 24 Sep 2020 01:21:43 -0700
+Subject: usb: dwc3: ep0: Fix ZLP for OUT ep0 requests
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 66706077dc89c66a4777a4c6298273816afb848c upstream.
+
+The current ZLP handling for ep0 requests is only for control IN
+requests. For OUT direction, DWC3 needs to check and setup for MPS
+alignment.
+
+Usually, control OUT requests can indicate its transfer size via the
+wLength field of the control message. So usb_request->zero is usually
+not needed for OUT direction. To handle ZLP OUT for control endpoint,
+make sure the TRB is MPS size.
+
+Cc: stable@vger.kernel.org
+Fixes: c7fcdeb2627c ("usb: dwc3: ep0: simplify EP0 state machine")
+Fixes: d6e5a549cc4d ("usb: dwc3: simplify ZLP handling")
+Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/ep0.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/dwc3/ep0.c
++++ b/drivers/usb/dwc3/ep0.c
+@@ -967,12 +967,16 @@ static void dwc3_ep0_xfer_complete(struc
+ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
+ struct dwc3_ep *dep, struct dwc3_request *req)
+ {
++ unsigned int trb_length = 0;
+ int ret;
+
+ req->direction = !!dep->number;
+
+ if (req->request.length == 0) {
+- dwc3_ep0_prepare_one_trb(dep, dwc->ep0_trb_addr, 0,
++ if (!req->direction)
++ trb_length = dep->endpoint.maxpacket;
++
++ dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr, trb_length,
+ DWC3_TRBCTL_CONTROL_DATA, false);
+ ret = dwc3_ep0_start_trans(dep);
+ } else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
+@@ -1024,9 +1028,12 @@ static void __dwc3_ep0_do_control_data(s
+
+ req->trb = &dwc->ep0_trb[dep->trb_enqueue - 1];
+
++ if (!req->direction)
++ trb_length = dep->endpoint.maxpacket;
++
+ /* Now prepare one extra TRB to align transfer size */
+ dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr,
+- 0, DWC3_TRBCTL_CONTROL_DATA,
++ trb_length, DWC3_TRBCTL_CONTROL_DATA,
+ false);
+ ret = dwc3_ep0_start_trans(dep);
+ } else {
--- /dev/null
+From 3cd54a618834430a26a648d880dd83d740f2ae30 Mon Sep 17 00:00:00 2001
+From: Ran Wang <ran.wang_1@nxp.com>
+Date: Sat, 10 Oct 2020 14:03:08 +0800
+Subject: usb: host: fsl-mph-dr-of: check return of dma_set_mask()
+
+From: Ran Wang <ran.wang_1@nxp.com>
+
+commit 3cd54a618834430a26a648d880dd83d740f2ae30 upstream.
+
+fsl_usb2_device_register() should stop init if dma_set_mask() return
+error.
+
+Fixes: cae058610465 ("drivers/usb/host: fsl: Set DMA_MASK of usb platform device")
+Reviewed-by: Peter Chen <peter.chen@nxp.com>
+Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
+Link: https://lore.kernel.org/r/20201010060308.33693-1-ran.wang_1@nxp.com
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/fsl-mph-dr-of.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/fsl-mph-dr-of.c
++++ b/drivers/usb/host/fsl-mph-dr-of.c
+@@ -98,10 +98,13 @@ static struct platform_device *fsl_usb2_
+
+ pdev->dev.coherent_dma_mask = ofdev->dev.coherent_dma_mask;
+
+- if (!pdev->dev.dma_mask)
++ if (!pdev->dev.dma_mask) {
+ pdev->dev.dma_mask = &ofdev->dev.coherent_dma_mask;
+- else
+- dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
++ } else {
++ retval = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
++ if (retval)
++ goto error;
++ }
+
+ retval = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+ if (retval)
--- /dev/null
+From 82e61c3909db51d91b9d3e2071557b6435018b80 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jirislaby@kernel.org>
+Date: Mon, 19 Oct 2020 10:55:17 +0200
+Subject: vt: keyboard, extend func_buf_lock to readers
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 82e61c3909db51d91b9d3e2071557b6435018b80 upstream.
+
+Both read-side users of func_table/func_buf need locking. Without that,
+one can easily confuse the code by repeatedly setting altering strings
+like:
+while (1)
+ for (a = 0; a < 2; a++) {
+ struct kbsentry kbs = {};
+ strcpy((char *)kbs.kb_string, a ? ".\n" : "88888\n");
+ ioctl(fd, KDSKBSENT, &kbs);
+ }
+
+When that program runs, one can get unexpected output by holding F1
+(note the unxpected period on the last line):
+.
+88888
+.8888
+
+So protect all accesses to 'func_table' (and func_buf) by preexisting
+'func_buf_lock'.
+
+It is easy in 'k_fn' handler as 'puts_queue' is expected not to sleep.
+On the other hand, KDGKBSENT needs a local (atomic) copy of the string
+because copy_to_user can sleep. Use already allocated, but unused
+'kbs->kb_string' for that purpose.
+
+Note that the program above needs at least CAP_SYS_TTY_CONFIG.
+
+This depends on the previous patch and on the func_buf_lock lock added
+in commit 46ca3f735f34 (tty/vt: fix write/write race in ioctl(KDSKBSENT)
+handler) in 5.2.
+
+Likely fixes CVE-2020-25656.
+
+Cc: <stable@vger.kernel.org>
+Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Link: https://lore.kernel.org/r/20201019085517.10176-2-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/keyboard.c | 17 +++++++++++++----
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/vt/keyboard.c
++++ b/drivers/tty/vt/keyboard.c
+@@ -713,8 +713,13 @@ static void k_fn(struct vc_data *vc, uns
+ return;
+
+ if ((unsigned)value < ARRAY_SIZE(func_table)) {
++ unsigned long flags;
++
++ spin_lock_irqsave(&func_buf_lock, flags);
+ if (func_table[value])
+ puts_queue(vc, func_table[value]);
++ spin_unlock_irqrestore(&func_buf_lock, flags);
++
+ } else
+ pr_err("k_fn called with value=%d\n", value);
+ }
+@@ -1959,7 +1964,7 @@ out:
+ #undef s
+ #undef v
+
+-/* FIXME: This one needs untangling and locking */
++/* FIXME: This one needs untangling */
+ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm)
+ {
+ struct kbsentry *kbs;
+@@ -1991,10 +1996,14 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb
+ switch (cmd) {
+ case KDGKBSENT: {
+ /* size should have been a struct member */
+- unsigned char *from = func_table[i] ? : "";
++ ssize_t len = sizeof(user_kdgkb->kb_string);
++
++ spin_lock_irqsave(&func_buf_lock, flags);
++ len = strlcpy(kbs->kb_string, func_table[i] ? : "", len);
++ spin_unlock_irqrestore(&func_buf_lock, flags);
+
+- ret = copy_to_user(user_kdgkb->kb_string, from,
+- strlen(from) + 1) ? -EFAULT : 0;
++ ret = copy_to_user(user_kdgkb->kb_string, kbs->kb_string,
++ len + 1) ? -EFAULT : 0;
+
+ goto reterr;
+ }
--- /dev/null
+From 6ca03f90527e499dd5e32d6522909e2ad390896b Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jirislaby@kernel.org>
+Date: Mon, 19 Oct 2020 10:55:16 +0200
+Subject: vt: keyboard, simplify vt_kdgkbsent
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 6ca03f90527e499dd5e32d6522909e2ad390896b upstream.
+
+Use 'strlen' of the string, add one for NUL terminator and simply do
+'copy_to_user' instead of the explicit 'for' loop. This makes the
+KDGKBSENT case more compact.
+
+The only thing we need to take care about is NULL 'func_table[i]'. Use
+an empty string in that case.
+
+The original check for overflow could never trigger as the func_buf
+strings are always shorter or equal to 'struct kbsentry's.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Link: https://lore.kernel.org/r/20201019085517.10176-1-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/keyboard.c | 28 +++++++++-------------------
+ 1 file changed, 9 insertions(+), 19 deletions(-)
+
+--- a/drivers/tty/vt/keyboard.c
++++ b/drivers/tty/vt/keyboard.c
+@@ -1963,9 +1963,7 @@ out:
+ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __user *user_kdgkb, int perm)
+ {
+ struct kbsentry *kbs;
+- char *p;
+ u_char *q;
+- u_char __user *up;
+ int sz, fnw_sz;
+ int delta;
+ char *first_free, *fj, *fnw;
+@@ -1991,23 +1989,15 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb
+ i = kbs->kb_func;
+
+ switch (cmd) {
+- case KDGKBSENT:
+- sz = sizeof(kbs->kb_string) - 1; /* sz should have been
+- a struct member */
+- up = user_kdgkb->kb_string;
+- p = func_table[i];
+- if(p)
+- for ( ; *p && sz; p++, sz--)
+- if (put_user(*p, up++)) {
+- ret = -EFAULT;
+- goto reterr;
+- }
+- if (put_user('\0', up)) {
+- ret = -EFAULT;
+- goto reterr;
+- }
+- kfree(kbs);
+- return ((p && *p) ? -EOVERFLOW : 0);
++ case KDGKBSENT: {
++ /* size should have been a struct member */
++ unsigned char *from = func_table[i] ? : "";
++
++ ret = copy_to_user(user_kdgkb->kb_string, from,
++ strlen(from) + 1) ? -EFAULT : 0;
++
++ goto reterr;
++ }
+ case KDSKBSENT:
+ if (!perm) {
+ ret = -EPERM;
--- /dev/null
+From c9723750a699c3bd465493ac2be8992b72ccb105 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Wed, 30 Sep 2020 10:36:46 +0200
+Subject: w1: mxc_w1: Fix timeout resolution problem leading to bus error
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+commit c9723750a699c3bd465493ac2be8992b72ccb105 upstream.
+
+On my platform (i.MX53) bus access sometimes fails with
+ w1_search: max_slave_count 64 reached, will continue next search.
+
+The reason is the use of jiffies to implement a 200us timeout in
+mxc_w1_ds2_touch_bit().
+On some platforms the jiffies timer resolution is insufficient for this.
+
+Fix by replacing jiffies by ktime_get().
+
+For consistency apply the same change to the other use of jiffies in
+mxc_w1_ds2_reset_bus().
+
+Fixes: f80b2581a706 ("w1: mxc_w1: Optimize mxc_w1_ds2_touch_bit()")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Link: https://lore.kernel.org/r/1601455030-6607-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/w1/masters/mxc_w1.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/w1/masters/mxc_w1.c
++++ b/drivers/w1/masters/mxc_w1.c
+@@ -15,7 +15,7 @@
+ #include <linux/clk.h>
+ #include <linux/delay.h>
+ #include <linux/io.h>
+-#include <linux/jiffies.h>
++#include <linux/ktime.h>
+ #include <linux/module.h>
+ #include <linux/platform_device.h>
+
+@@ -47,12 +47,12 @@ struct mxc_w1_device {
+ static u8 mxc_w1_ds2_reset_bus(void *data)
+ {
+ struct mxc_w1_device *dev = data;
+- unsigned long timeout;
++ ktime_t timeout;
+
+ writeb(MXC_W1_CONTROL_RPP, dev->regs + MXC_W1_CONTROL);
+
+ /* Wait for reset sequence 511+512us, use 1500us for sure */
+- timeout = jiffies + usecs_to_jiffies(1500);
++ timeout = ktime_add_us(ktime_get(), 1500);
+
+ udelay(511 + 512);
+
+@@ -62,7 +62,7 @@ static u8 mxc_w1_ds2_reset_bus(void *dat
+ /* PST bit is valid after the RPP bit is self-cleared */
+ if (!(ctrl & MXC_W1_CONTROL_RPP))
+ return !(ctrl & MXC_W1_CONTROL_PST);
+- } while (time_is_after_jiffies(timeout));
++ } while (ktime_before(ktime_get(), timeout));
+
+ return 1;
+ }
+@@ -75,12 +75,12 @@ static u8 mxc_w1_ds2_reset_bus(void *dat
+ static u8 mxc_w1_ds2_touch_bit(void *data, u8 bit)
+ {
+ struct mxc_w1_device *dev = data;
+- unsigned long timeout;
++ ktime_t timeout;
+
+ writeb(MXC_W1_CONTROL_WR(bit), dev->regs + MXC_W1_CONTROL);
+
+ /* Wait for read/write bit (60us, Max 120us), use 200us for sure */
+- timeout = jiffies + usecs_to_jiffies(200);
++ timeout = ktime_add_us(ktime_get(), 200);
+
+ udelay(60);
+
+@@ -90,7 +90,7 @@ static u8 mxc_w1_ds2_touch_bit(void *dat
+ /* RDST bit is valid after the WR1/RD bit is self-cleared */
+ if (!(ctrl & MXC_W1_CONTROL_WR(bit)))
+ return !!(ctrl & MXC_W1_CONTROL_RDST);
+- } while (time_is_after_jiffies(timeout));
++ } while (ktime_before(ktime_get(), timeout));
+
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
