--- /dev/null
+From 90268574a3e8a6b883bd802d702a2738577e1006 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Mon, 23 Aug 2021 11:12:53 +0100
+Subject: arm64: head: avoid over-mapping in map_memory
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit 90268574a3e8a6b883bd802d702a2738577e1006 upstream.
+
+The `compute_indices` and `populate_entries` macros operate on inclusive
+bounds, and thus the `map_memory` macro which uses them also operates
+on inclusive bounds.
+
+We pass `_end` and `_idmap_text_end` to `map_memory`, but these are
+exclusive bounds, and if one of these is sufficiently aligned (as a
+result of kernel configuration, physical placement, and KASLR), then:
+
+* In `compute_indices`, the computed `iend` will be in the page/block *after*
+ the final byte of the intended mapping.
+
+* In `populate_entries`, an unnecessary entry will be created at the end
+ of each level of table. At the leaf level, this entry will map up to
+ SWAPPER_BLOCK_SIZE bytes of physical addresses that we did not intend
+ to map.
+
+As we may map up to SWAPPER_BLOCK_SIZE bytes more than intended, we may
+violate the boot protocol and map physical address past the 2MiB-aligned
+end address we are permitted to map. As we map these with Normal memory
+attributes, this may result in further problems depending on what these
+physical addresses correspond to.
+
+The final entry at each level may require an additional table at that
+level. As EARLY_ENTRIES() calculates an inclusive bound, we allocate
+enough memory for this.
+
+Avoid the extraneous mapping by having map_memory convert the exclusive
+end address to an inclusive end address by subtracting one, and do
+likewise in EARLY_ENTRIES() when calculating the number of required
+tables. For clarity, comments are updated to more clearly document which
+boundaries the macros operate on. For consistency with the other
+macros, the comments in map_memory are also updated to describe `vstart`
+and `vend` as virtual addresses.
+
+Fixes: 0370b31e4845 ("arm64: Extend early page table code to allow for larger kernels")
+Cc: <stable@vger.kernel.org> # 4.16.x
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Cc: Steve Capper <steve.capper@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20210823101253.55567-1-mark.rutland@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
+ arch/arm64/kernel/head.S | 11 ++++++-----
+ 2 files changed, 8 insertions(+), 7 deletions(-)
+
+--- a/arch/arm64/include/asm/kernel-pgtable.h
++++ b/arch/arm64/include/asm/kernel-pgtable.h
+@@ -65,8 +65,8 @@
+ #define EARLY_KASLR (0)
+ #endif
+
+-#define EARLY_ENTRIES(vstart, vend, shift) (((vend) >> (shift)) \
+- - ((vstart) >> (shift)) + 1 + EARLY_KASLR)
++#define EARLY_ENTRIES(vstart, vend, shift) \
++ ((((vend) - 1) >> (shift)) - ((vstart) >> (shift)) + 1 + EARLY_KASLR)
+
+ #define EARLY_PGDS(vstart, vend) (EARLY_ENTRIES(vstart, vend, PGDIR_SHIFT))
+
+--- a/arch/arm64/kernel/head.S
++++ b/arch/arm64/kernel/head.S
+@@ -194,7 +194,7 @@ ENDPROC(preserve_boot_args)
+ * to be composed of multiple pages. (This effectively scales the end index).
+ *
+ * vstart: virtual address of start of range
+- * vend: virtual address of end of range
++ * vend: virtual address of end of range - we map [vstart, vend]
+ * shift: shift used to transform virtual address into index
+ * ptrs: number of entries in page table
+ * istart: index in table corresponding to vstart
+@@ -231,17 +231,18 @@ ENDPROC(preserve_boot_args)
+ *
+ * tbl: location of page table
+ * rtbl: address to be used for first level page table entry (typically tbl + PAGE_SIZE)
+- * vstart: start address to map
+- * vend: end address to map - we map [vstart, vend]
++ * vstart: virtual address of start of range
++ * vend: virtual address of end of range - we map [vstart, vend - 1]
+ * flags: flags to use to map last level entries
+ * phys: physical address corresponding to vstart - physical memory is contiguous
+ * pgds: the number of pgd entries
+ *
+ * Temporaries: istart, iend, tmp, count, sv - these need to be different registers
+- * Preserves: vstart, vend, flags
+- * Corrupts: tbl, rtbl, istart, iend, tmp, count, sv
++ * Preserves: vstart, flags
++ * Corrupts: tbl, rtbl, vend, istart, iend, tmp, count, sv
+ */
+ .macro map_memory, tbl, rtbl, vstart, vend, flags, phys, pgds, istart, iend, tmp, count, sv
++ sub \vend, \vend, #1
+ add \rtbl, \tbl, #PAGE_SIZE
+ mov \sv, \rtbl
+ mov \count, #0
--- /dev/null
+From a680dd72ec336b81511e3bff48efac6dbfa563e7 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@wdc.com>
+Date: Wed, 11 Aug 2021 12:36:57 +0900
+Subject: block: bfq: fix bfq_set_next_ioprio_data()
+
+From: Damien Le Moal <damien.lemoal@wdc.com>
+
+commit a680dd72ec336b81511e3bff48efac6dbfa563e7 upstream.
+
+For a request that has a priority level equal to or larger than
+IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but
+defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This
+is not consistent with the warning and the allowed values for priority
+levels. Fix this by setting the request new_ioprio field to
+IOPRIO_BE_NR - 1, the lowest priority level allowed.
+
+Cc: <stable@vger.kernel.org>
+Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler")
+Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Link: https://lore.kernel.org/r/20210811033702.368488-2-damien.lemoal@wdc.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/bfq-iosched.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -5004,7 +5004,7 @@ bfq_set_next_ioprio_data(struct bfq_queu
+ if (bfqq->new_ioprio >= IOPRIO_BE_NR) {
+ pr_crit("bfq_set_next_ioprio_data: new_ioprio %d\n",
+ bfqq->new_ioprio);
+- bfqq->new_ioprio = IOPRIO_BE_NR;
++ bfqq->new_ioprio = IOPRIO_BE_NR - 1;
+ }
+
+ bfqq->entity.new_weight = bfq_ioprio_to_weight(bfqq->new_ioprio);
--- /dev/null
+From e5c6b312ce3cc97e90ea159446e6bfa06645364d Mon Sep 17 00:00:00 2001
+From: Kevin Hao <haokexin@gmail.com>
+Date: Thu, 5 Aug 2021 15:29:17 +0800
+Subject: cpufreq: schedutil: Use kobject release() method to free sugov_tunables
+
+From: Kevin Hao <haokexin@gmail.com>
+
+commit e5c6b312ce3cc97e90ea159446e6bfa06645364d upstream.
+
+The struct sugov_tunables is protected by the kobject, so we can't free
+it directly. Otherwise we would get a call trace like this:
+ ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
+ WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
+ Modules linked in:
+ CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507
+ Hardware name: Marvell OcteonTX CN96XX board (DT)
+ pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
+ pc : debug_print_object+0xb8/0x100
+ lr : debug_print_object+0xb8/0x100
+ sp : ffff80001ecaf910
+ x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
+ x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000
+ x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
+ x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010
+ x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365
+ x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69
+ x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0
+ x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001
+ x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000
+ x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000
+ Call trace:
+ debug_print_object+0xb8/0x100
+ __debug_check_no_obj_freed+0x1c0/0x230
+ debug_check_no_obj_freed+0x20/0x88
+ slab_free_freelist_hook+0x154/0x1c8
+ kfree+0x114/0x5d0
+ sugov_exit+0xbc/0xc0
+ cpufreq_exit_governor+0x44/0x90
+ cpufreq_set_policy+0x268/0x4a8
+ store_scaling_governor+0xe0/0x128
+ store+0xc0/0xf0
+ sysfs_kf_write+0x54/0x80
+ kernfs_fop_write_iter+0x128/0x1c0
+ new_sync_write+0xf0/0x190
+ vfs_write+0x2d4/0x478
+ ksys_write+0x74/0x100
+ __arm64_sys_write+0x24/0x30
+ invoke_syscall.constprop.0+0x54/0xe0
+ do_el0_svc+0x64/0x158
+ el0_svc+0x2c/0xb0
+ el0t_64_sync_handler+0xb0/0xb8
+ el0t_64_sync+0x198/0x19c
+ irq event stamp: 5518
+ hardirqs last enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8
+ hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0
+ softirqs last enabled at (5504): [<ffff8000100106e0>] __do_softirq+0x4d0/0x6c0
+ softirqs last disabled at (5483): [<ffff800010049548>] irq_exit+0x1b0/0x1b8
+
+So split the original sugov_tunables_free() into two functions,
+sugov_clear_global_tunables() is just used to clear the global_tunables
+and the new sugov_tunables_free() is used as kobj_type::release to
+release the sugov_tunables safely.
+
+Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data")
+Cc: 4.7+ <stable@vger.kernel.org> # 4.7+
+Signed-off-by: Kevin Hao <haokexin@gmail.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/cpufreq_schedutil.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/kernel/sched/cpufreq_schedutil.c
++++ b/kernel/sched/cpufreq_schedutil.c
+@@ -624,9 +624,17 @@ static struct attribute *sugov_attrs[] =
+ };
+ ATTRIBUTE_GROUPS(sugov);
+
++static void sugov_tunables_free(struct kobject *kobj)
++{
++ struct gov_attr_set *attr_set = container_of(kobj, struct gov_attr_set, kobj);
++
++ kfree(to_sugov_tunables(attr_set));
++}
++
+ static struct kobj_type sugov_tunables_ktype = {
+ .default_groups = sugov_groups,
+ .sysfs_ops = &governor_sysfs_ops,
++ .release = &sugov_tunables_free,
+ };
+
+ /********************** cpufreq governor interface *********************/
+@@ -726,12 +734,10 @@ static struct sugov_tunables *sugov_tuna
+ return tunables;
+ }
+
+-static void sugov_tunables_free(struct sugov_tunables *tunables)
++static void sugov_clear_global_tunables(void)
+ {
+ if (!have_governor_per_policy())
+ global_tunables = NULL;
+-
+- kfree(tunables);
+ }
+
+ static int sugov_init(struct cpufreq_policy *policy)
+@@ -794,7 +800,7 @@ out:
+ fail:
+ kobject_put(&tunables->attr_set.kobj);
+ policy->governor_data = NULL;
+- sugov_tunables_free(tunables);
++ sugov_clear_global_tunables();
+
+ stop_kthread:
+ sugov_kthread_stop(sg_policy);
+@@ -821,7 +827,7 @@ static void sugov_exit(struct cpufreq_po
+ count = gov_attr_set_put(&tunables->attr_set, &sg_policy->tunables_hook);
+ policy->governor_data = NULL;
+ if (!count)
+- sugov_tunables_free(tunables);
++ sugov_clear_global_tunables();
+
+ mutex_unlock(&global_tunables_lock);
+
--- /dev/null
+From f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a Mon Sep 17 00:00:00 2001
+From: zhenwei pi <pizhenwei@bytedance.com>
+Date: Thu, 19 Aug 2021 20:37:10 +0800
+Subject: crypto: public_key: fix overflow during implicit conversion
+
+From: zhenwei pi <pizhenwei@bytedance.com>
+
+commit f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a upstream.
+
+Hit kernel warning like this, it can be reproduced by verifying 256
+bytes datafile by keyctl command, run script:
+RAWDATA=rawdata
+SIGDATA=sigdata
+
+modprobe pkcs8_key_parser
+
+rm -rf *.der *.pem *.pfx
+rm -rf $RAWDATA
+dd if=/dev/random of=$RAWDATA bs=256 count=1
+
+openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
+ -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com"
+
+KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \
+ padd asymmetric 123 @s`
+
+keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA
+keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1
+
+Then the kernel reports:
+ WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540
+ pkcs1pad_verify+0x160/0x190
+ ...
+ Call Trace:
+ public_key_verify_signature+0x282/0x380
+ ? software_key_query+0x12d/0x180
+ ? keyctl_pkey_params_get+0xd6/0x130
+ asymmetric_key_verify_signature+0x66/0x80
+ keyctl_pkey_verify+0xa5/0x100
+ do_syscall_64+0x35/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+The reason of this issue, in function 'asymmetric_key_verify_signature':
+'.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value,
+so use u32 instead of u8 for digest_size field. And reorder struct
+public_key_signature, it saves 8 bytes on a 64-bit machine.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/crypto/public_key.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/crypto/public_key.h
++++ b/include/crypto/public_key.h
+@@ -38,9 +38,9 @@ extern void public_key_free(struct publi
+ struct public_key_signature {
+ struct asymmetric_key_id *auth_ids[2];
+ u8 *s; /* Signature */
+- u32 s_size; /* Number of bytes in signature */
+ u8 *digest;
+- u8 digest_size; /* Number of bytes in digest */
++ u32 s_size; /* Number of bytes in signature */
++ u32 digest_size; /* Number of bytes in digest */
+ const char *pkey_algo;
+ const char *hash_algo;
+ const char *encoding;
--- /dev/null
+From 528b16bfc3ae5f11638e71b3b63a81f9999df727 Mon Sep 17 00:00:00 2001
+From: Arne Welzel <arne.welzel@corelight.com>
+Date: Sat, 14 Aug 2021 00:40:38 +0200
+Subject: dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc()
+
+From: Arne Welzel <arne.welzel@corelight.com>
+
+commit 528b16bfc3ae5f11638e71b3b63a81f9999df727 upstream.
+
+On systems with many cores using dm-crypt, heavy spinlock contention in
+percpu_counter_compare() can be observed when the page allocation limit
+for a given device is reached or close to be reached. This is due
+to percpu_counter_compare() taking a spinlock to compute an exact
+result on potentially many CPUs at the same time.
+
+Switch to non-exact comparison of allocated and allowed pages by using
+the value returned by percpu_counter_read_positive() to avoid taking
+the percpu_counter spinlock.
+
+This may over/under estimate the actual number of allocated pages by at
+most (batch-1) * num_online_cpus().
+
+Currently, batch is bounded by 32. The system on which this issue was
+first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this
+change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt
+allocations, this seems an acceptable error. Certainly preferred over
+running into the spinlock contention.
+
+This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs
+and 192GB RAM as follows, but can be provoked on systems with less CPUs
+as well.
+
+ * Disable swap
+ * Tune vm settings to promote regular writeback
+ $ echo 50 > /proc/sys/vm/dirty_expire_centisecs
+ $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs
+ $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes
+
+ * Create 8 dmcrypt devices based on files on a tmpfs
+ * Create and mount an ext4 filesystem on each crypt devices
+ * Run stress-ng --hdd 8 within one of above filesystems
+
+Total %system usage collected from sysstat goes to ~35%. Write throughput
+on the underlying loop device is ~2GB/s. perf profiling an individual
+kworker kcryptd thread shows the following profile, indicating spinlock
+contention in percpu_counter_compare():
+
+ 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork
+ |
+ --ret_from_fork
+ kthread
+ worker_thread
+ |
+ --99.92%--process_one_work
+ |
+ |--80.52%--kcryptd_crypt
+ | |
+ | |--62.58%--mempool_alloc
+ | | |
+ | | --62.24%--crypt_page_alloc
+ | | |
+ | | --61.51%--__percpu_counter_compare
+ | | |
+ | | --61.34%--__percpu_counter_sum
+ | | |
+ | | |--58.68%--_raw_spin_lock_irqsave
+ | | | |
+ | | | --58.30%--native_queued_spin_lock_slowpath
+ | | |
+ | | --0.69%--cpumask_next
+ | | |
+ | | --0.51%--_find_next_bit
+ | |
+ | |--10.61%--crypt_convert
+ | | |
+ | | |--6.05%--xts_crypt
+ ...
+
+After applying this patch and running the same test, %system usage is
+lowered to ~7% and write throughput on the loop device increases
+to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62%
+in the profile and not hitting the percpu_counter() spinlock anymore.
+
+ |--8.15%--mempool_alloc
+ | |
+ | |--3.93%--crypt_page_alloc
+ | | |
+ | | --3.75%--__alloc_pages
+ | | |
+ | | --3.62%--get_page_from_freelist
+ | | |
+ | | --3.22%--rmqueue_bulk
+ | | |
+ | | --2.59%--_raw_spin_lock
+ | | |
+ | | --2.57%--native_queued_spin_lock_slowpath
+ | |
+ | --3.05%--_raw_spin_lock_irqsave
+ | |
+ | --2.49%--native_queued_spin_lock_slowpath
+
+Suggested-by: DJ Gregor <dj@corelight.com>
+Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Arne Welzel <arne.welzel@corelight.com>
+Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-crypt.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-crypt.c
++++ b/drivers/md/dm-crypt.c
+@@ -2092,7 +2092,12 @@ static void *crypt_page_alloc(gfp_t gfp_
+ struct crypt_config *cc = pool_data;
+ struct page *page;
+
+- if (unlikely(percpu_counter_compare(&cc->n_allocated_pages, dm_crypt_pages_per_client) >= 0) &&
++ /*
++ * Note, percpu_counter_read_positive() may over (and under) estimate
++ * the current usage by at most (batch - 1) * num_online_cpus() pages,
++ * but avoids potential spinlock contention of an exact result.
++ */
++ if (unlikely(percpu_counter_read_positive(&cc->n_allocated_pages) >= dm_crypt_pages_per_client) &&
+ likely(gfp_mask & __GFP_NORETRY))
+ return NULL;
+
--- /dev/null
+From e555a03b112838883fdd8185d613c35d043732f2 Mon Sep 17 00:00:00 2001
+From: Robin Gong <yibin.gong@nxp.com>
+Date: Wed, 14 Jul 2021 18:20:44 +0800
+Subject: dmaengine: imx-sdma: remove duplicated sdma_load_context
+
+From: Robin Gong <yibin.gong@nxp.com>
+
+commit e555a03b112838883fdd8185d613c35d043732f2 upstream.
+
+Since sdma_transfer_init() will do sdma_load_context before any
+sdma transfer, no need once more in sdma_config_channel().
+
+Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Robin Gong <yibin.gong@nxp.com>
+Acked-by: Vinod Koul <vkoul@kernel.org>
+Tested-by: Richard Leitner <richard.leitner@skidata.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/imx-sdma.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1134,7 +1134,6 @@ static void sdma_set_watermarklevel_for_
+ static int sdma_config_channel(struct dma_chan *chan)
+ {
+ struct sdma_channel *sdmac = to_sdma_chan(chan);
+- int ret;
+
+ sdma_disable_channel(chan);
+
+@@ -1174,9 +1173,7 @@ static int sdma_config_channel(struct dm
+ sdmac->watermark_level = 0; /* FIXME: M3_BASE_ADDRESS */
+ }
+
+- ret = sdma_load_context(sdmac);
+-
+- return ret;
++ return 0;
+ }
+
+ static int sdma_set_channel_priority(struct sdma_channel *sdmac,
--- /dev/null
+From 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Sat, 3 Jul 2021 15:37:17 +0200
+Subject: media: rc-loopback: return number of emitters rather than error
+
+From: Sean Young <sean@mess.org>
+
+commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream.
+
+The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters
+if an invalid list was set.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/rc-loopback.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/rc/rc-loopback.c
++++ b/drivers/media/rc/rc-loopback.c
+@@ -42,7 +42,7 @@ static int loop_set_tx_mask(struct rc_de
+
+ if ((mask & (RXMASK_REGULAR | RXMASK_LEARNING)) != mask) {
+ dprintk("invalid tx mask: %u\n", mask);
+- return -EINVAL;
++ return 2;
+ }
+
+ dprintk("setting tx mask: %u\n", mask);
--- /dev/null
+From 1a10d7fdb6d0e235e9d230916244cc2769d3f170 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Date: Thu, 17 Jun 2021 14:33:29 +0200
+Subject: media: uvc: don't do DMA on stack
+
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+
+commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream.
+
+As warned by smatch:
+ drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i)
+ drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i)
+
+those two functions call uvc_query_ctrl passing a pointer to
+a data at the DMA stack. those are used to send URBs via
+usb_control_msg(). Using DMA stack is not supported and should
+not work anymore on modern Linux versions.
+
+So, use a kmalloc'ed buffer.
+
+Cc: stable@vger.kernel.org # Kernel 4.9 and upper
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_v4l2.c | 34 +++++++++++++++++++++++-----------
+ 1 file changed, 23 insertions(+), 11 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_v4l2.c
++++ b/drivers/media/usb/uvc/uvc_v4l2.c
+@@ -894,8 +894,8 @@ static int uvc_ioctl_g_input(struct file
+ {
+ struct uvc_fh *handle = fh;
+ struct uvc_video_chain *chain = handle->chain;
++ u8 *buf;
+ int ret;
+- u8 i;
+
+ if (chain->selector == NULL ||
+ (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
+@@ -903,22 +903,27 @@ static int uvc_ioctl_g_input(struct file
+ return 0;
+ }
+
++ buf = kmalloc(1, GFP_KERNEL);
++ if (!buf)
++ return -ENOMEM;
++
+ ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR, chain->selector->id,
+ chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL,
+- &i, 1);
+- if (ret < 0)
+- return ret;
++ buf, 1);
++ if (!ret)
++ *input = *buf - 1;
+
+- *input = i - 1;
+- return 0;
++ kfree(buf);
++
++ return ret;
+ }
+
+ static int uvc_ioctl_s_input(struct file *file, void *fh, unsigned int input)
+ {
+ struct uvc_fh *handle = fh;
+ struct uvc_video_chain *chain = handle->chain;
++ u8 *buf;
+ int ret;
+- u32 i;
+
+ ret = uvc_acquire_privileges(handle);
+ if (ret < 0)
+@@ -934,10 +939,17 @@ static int uvc_ioctl_s_input(struct file
+ if (input >= chain->selector->bNrInPins)
+ return -EINVAL;
+
+- i = input + 1;
+- return uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id,
+- chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL,
+- &i, 1);
++ buf = kmalloc(1, GFP_KERNEL);
++ if (!buf)
++ return -ENOMEM;
++
++ *buf = input + 1;
++ ret = uvc_query_ctrl(chain->dev, UVC_SET_CUR, chain->selector->id,
++ chain->dev->intfnum, UVC_SU_INPUT_SELECT_CONTROL,
++ buf, 1);
++ kfree(buf);
++
++ return ret;
+ }
+
+ static int uvc_ioctl_queryctrl(struct file *file, void *fh,
--- /dev/null
+From d5e931403942b3af39212960c2592b5ba741b2bf Mon Sep 17 00:00:00 2001
+From: Paul Cercueil <paul@crapouillou.net>
+Date: Sat, 17 Jul 2021 18:48:34 +0100
+Subject: pinctrl: ingenic: Fix incorrect pull up/down info
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Paul Cercueil <paul@crapouillou.net>
+
+commit d5e931403942b3af39212960c2592b5ba741b2bf upstream.
+
+Fix the pull up/down info for both the JZ4760 and JZ4770 SoCs, as the
+previous values sometimes contradicted what's written in the programming
+manual.
+
+Fixes: b5c23aa46537 ("pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs")
+Cc: <stable@vger.kernel.org> # v4.12
+Signed-off-by: Paul Cercueil <paul@crapouillou.net>
+Tested-by: 周琰杰 (Zhou Yanjie)<zhouyanjie@wanyeetech.com>
+Link: https://lore.kernel.org/r/20210717174836.14776-1-paul@crapouillou.net
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/pinctrl-ingenic.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-ingenic.c
++++ b/drivers/pinctrl/pinctrl-ingenic.c
+@@ -348,7 +348,7 @@ static const struct ingenic_chip_info jz
+ };
+
+ static const u32 jz4760_pull_ups[6] = {
+- 0xffffffff, 0xfffcf3ff, 0xffffffff, 0xffffcfff, 0xfffffb7c, 0xfffff00f,
++ 0xffffffff, 0xfffcf3ff, 0xffffffff, 0xffffcfff, 0xfffffb7c, 0x0000000f,
+ };
+
+ static const u32 jz4760_pull_downs[6] = {
+@@ -611,11 +611,11 @@ static const struct ingenic_chip_info jz
+ };
+
+ static const u32 jz4770_pull_ups[6] = {
+- 0x3fffffff, 0xfff0030c, 0xffffffff, 0xffff4fff, 0xfffffb7c, 0xffa7f00f,
++ 0x3fffffff, 0xfff0f3fc, 0xffffffff, 0xffff4fff, 0xfffffb7c, 0x0024f00f,
+ };
+
+ static const u32 jz4770_pull_downs[6] = {
+- 0x00000000, 0x000f0c03, 0x00000000, 0x0000b000, 0x00000483, 0x00580ff0,
++ 0x00000000, 0x000f0c03, 0x00000000, 0x0000b000, 0x00000483, 0x005b0ff0,
+ };
+
+ static int jz4770_uart0_data_pins[] = { 0xa0, 0xa3, };
--- /dev/null
+From 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Sun, 25 Jul 2021 19:08:30 +0100
+Subject: pinctrl: stmfx: Fix hazardous u8[] to unsigned long cast
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 upstream.
+
+Casting a small array of u8 to an unsigned long is *never* OK:
+
+- it does funny thing when the array size is less than that of a long,
+ as it accesses random places in the stack
+- it makes everything even more fun with a BE kernel
+
+Fix this by building the unsigned long used as a bitmap byte by byte,
+in a way that works across endianess and has no undefined behaviours.
+
+An extra BUILD_BUG_ON() catches the unlikely case where the array
+would be larger than a single unsigned long.
+
+Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver")
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Cc: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: Linus Walleij <linus.walleij@linaro.org>
+Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
+Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
+Link: https://lore.kernel.org/r/20210725180830.250218-1-maz@kernel.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/pinctrl-stmfx.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-stmfx.c
++++ b/drivers/pinctrl/pinctrl-stmfx.c
+@@ -540,7 +540,7 @@ static irqreturn_t stmfx_pinctrl_irq_thr
+ u8 pending[NR_GPIO_REGS];
+ u8 src[NR_GPIO_REGS] = {0, 0, 0};
+ unsigned long n, status;
+- int ret;
++ int i, ret;
+
+ ret = regmap_bulk_read(pctl->stmfx->map, STMFX_REG_IRQ_GPI_PENDING,
+ &pending, NR_GPIO_REGS);
+@@ -550,7 +550,9 @@ static irqreturn_t stmfx_pinctrl_irq_thr
+ regmap_bulk_write(pctl->stmfx->map, STMFX_REG_IRQ_GPI_SRC,
+ src, NR_GPIO_REGS);
+
+- status = *(unsigned long *)pending;
++ BUILD_BUG_ON(NR_GPIO_REGS > sizeof(status));
++ for (i = 0, status = 0; i < NR_GPIO_REGS; i++)
++ status |= (unsigned long)pending[i] << (i * 8);
+ for_each_set_bit(n, &status, gc->ngpio) {
+ handle_nested_irq(irq_find_mapping(gc->irq.domain, n));
+ stmfx_pinctrl_irq_toggle_trigger(pctl, n);
--- /dev/null
+From 54784ffa5b267f57161eb8fbb811499f22a0a0bf Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Date: Mon, 16 Aug 2021 10:27:14 +0200
+Subject: power: supply: max17042: handle fails of reading status register
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+
+commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream.
+
+Reading status register can fail in the interrupt handler. In such
+case, the regmap_read() will not store anything useful under passed
+'val' variable and random stack value will be used to determine type of
+interrupt.
+
+Handle the regmap_read() failure to avoid handling interrupt type and
+triggering changed power supply event based on random stack value.
+
+Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/max17042_battery.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/power/supply/max17042_battery.c
++++ b/drivers/power/supply/max17042_battery.c
+@@ -842,8 +842,12 @@ static irqreturn_t max17042_thread_handl
+ {
+ struct max17042_chip *chip = dev;
+ u32 val;
++ int ret;
++
++ ret = regmap_read(chip->regmap, MAX17042_STATUS, &val);
++ if (ret)
++ return IRQ_HANDLED;
+
+- regmap_read(chip->regmap, MAX17042_STATUS, &val);
+ if ((val & STATUS_INTR_SOCMIN_BIT) ||
+ (val & STATUS_INTR_SOCMAX_BIT)) {
+ dev_info(&chip->client->dev, "SOC threshold INTR\n");
--- /dev/null
+From 8592f02464d52776c5cfae4627c6413b0ae7602d Mon Sep 17 00:00:00 2001
+From: Robin Gong <yibin.gong@nxp.com>
+Date: Wed, 14 Jul 2021 18:20:43 +0800
+Subject: Revert "dmaengine: imx-sdma: refine to load context only once"
+
+From: Robin Gong <yibin.gong@nxp.com>
+
+commit 8592f02464d52776c5cfae4627c6413b0ae7602d upstream.
+
+This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because
+in spi-imx case, burst length may be changed dynamically.
+
+Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Robin Gong <yibin.gong@nxp.com>
+Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
+Tested-by: Richard Leitner <richard.leitner@skidata.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/imx-sdma.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -377,7 +377,6 @@ struct sdma_channel {
+ unsigned long watermark_level;
+ u32 shp_addr, per_addr;
+ enum dma_status status;
+- bool context_loaded;
+ struct imx_dma_data data;
+ struct work_struct terminate_worker;
+ };
+@@ -988,9 +987,6 @@ static int sdma_load_context(struct sdma
+ int ret;
+ unsigned long flags;
+
+- if (sdmac->context_loaded)
+- return 0;
+-
+ if (sdmac->direction == DMA_DEV_TO_MEM)
+ load_address = sdmac->pc_from_device;
+ else if (sdmac->direction == DMA_DEV_TO_DEV)
+@@ -1033,8 +1029,6 @@ static int sdma_load_context(struct sdma
+
+ spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
+
+- sdmac->context_loaded = true;
+-
+ return ret;
+ }
+
+@@ -1074,7 +1068,6 @@ static void sdma_channel_terminate_work(
+ sdmac->desc = NULL;
+ spin_unlock_irqrestore(&sdmac->vc.lock, flags);
+ vchan_dma_desc_free_list(&sdmac->vc, &head);
+- sdmac->context_loaded = false;
+ }
+
+ static int sdma_disable_channel_async(struct dma_chan *chan)
+@@ -1335,7 +1328,6 @@ static void sdma_free_chan_resources(str
+
+ sdmac->event_id0 = 0;
+ sdmac->event_id1 = 0;
+- sdmac->context_loaded = false;
+
+ sdma_set_channel_priority(sdmac, 0);
+
xen-fix-setting-of-max_pfn-in-shared_info.patch
include-linux-list.h-add-a-macro-to-test-if-entry-is-pointing-to-the-head.patch
9p-xen-fix-end-of-loop-tests-for-list_for_each_entry.patch
+tools-thermal-tmon-add-cross-compiling-support.patch
+pinctrl-stmfx-fix-hazardous-u8-to-unsigned-long-cast.patch
+pinctrl-ingenic-fix-incorrect-pull-up-down-info.patch
+soc-qcom-aoss-fix-the-out-of-bound-usage-of-cooling_devs.patch
+soc-aspeed-lpc-ctrl-fix-boundary-check-for-mmap.patch
+soc-aspeed-p2a-ctrl-fix-boundary-check-for-mmap.patch
+arm64-head-avoid-over-mapping-in-map_memory.patch
+crypto-public_key-fix-overflow-during-implicit-conversion.patch
+block-bfq-fix-bfq_set_next_ioprio_data.patch
+power-supply-max17042-handle-fails-of-reading-status-register.patch
+cpufreq-schedutil-use-kobject-release-method-to-free-sugov_tunables.patch
+dm-crypt-avoid-percpu_counter-spinlock-contention-in-crypt_page_alloc.patch
+vmci-fix-null-pointer-dereference-when-unmapping-queue-pair.patch
+media-uvc-don-t-do-dma-on-stack.patch
+media-rc-loopback-return-number-of-emitters-rather-than-error.patch
+revert-dmaengine-imx-sdma-refine-to-load-context-only-once.patch
+dmaengine-imx-sdma-remove-duplicated-sdma_load_context.patch
--- /dev/null
+From b49a0e69a7b1a68c8d3f64097d06dabb770fec96 Mon Sep 17 00:00:00 2001
+From: Iwona Winiarska <iwona.winiarska@intel.com>
+Date: Wed, 4 Aug 2021 01:48:18 +0200
+Subject: soc: aspeed: lpc-ctrl: Fix boundary check for mmap
+
+From: Iwona Winiarska <iwona.winiarska@intel.com>
+
+commit b49a0e69a7b1a68c8d3f64097d06dabb770fec96 upstream.
+
+The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one
+side of the comparison, and uses resource address (rather than just the
+resource size) on the other side of the comparison.
+This can allow malicious userspace to easily bypass the boundary check and
+map pages that are located outside memory-region reserved by the driver.
+
+Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
+Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
+Tested-by: Andrew Jeffery <andrew@aj.id.au>
+Reviewed-by: Joel Stanley <joel@aj.id.au>
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/aspeed/aspeed-lpc-ctrl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
++++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+@@ -46,7 +46,7 @@ static int aspeed_lpc_ctrl_mmap(struct f
+ unsigned long vsize = vma->vm_end - vma->vm_start;
+ pgprot_t prot = vma->vm_page_prot;
+
+- if (vma->vm_pgoff + vsize > lpc_ctrl->mem_base + lpc_ctrl->mem_size)
++ if (vma->vm_pgoff + vma_pages(vma) > lpc_ctrl->mem_size >> PAGE_SHIFT)
+ return -EINVAL;
+
+ /* ast2400/2500 AHB accesses are not cache coherent */
--- /dev/null
+From 8b07e990fb254fcbaa919616ac77f981cb48c73d Mon Sep 17 00:00:00 2001
+From: Iwona Winiarska <iwona.winiarska@intel.com>
+Date: Wed, 4 Aug 2021 01:48:19 +0200
+Subject: soc: aspeed: p2a-ctrl: Fix boundary check for mmap
+
+From: Iwona Winiarska <iwona.winiarska@intel.com>
+
+commit 8b07e990fb254fcbaa919616ac77f981cb48c73d upstream.
+
+The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one
+side of the comparison, and uses resource address (rather than just the
+resource size) on the other side of the comparison.
+This can allow malicious userspace to easily bypass the boundary check and
+map pages that are located outside memory-region reserved by the driver.
+
+Fixes: 01c60dcea9f7 ("drivers/misc: Add Aspeed P2A control driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
+Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
+Tested-by: Andrew Jeffery <andrew@aj.id.au>
+Reviewed-by: Joel Stanley <joel@aj.id.au>
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/aspeed/aspeed-p2a-ctrl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soc/aspeed/aspeed-p2a-ctrl.c
++++ b/drivers/soc/aspeed/aspeed-p2a-ctrl.c
+@@ -110,7 +110,7 @@ static int aspeed_p2a_mmap(struct file *
+ vsize = vma->vm_end - vma->vm_start;
+ prot = vma->vm_page_prot;
+
+- if (vma->vm_pgoff + vsize > ctrl->mem_base + ctrl->mem_size)
++ if (vma->vm_pgoff + vma_pages(vma) > ctrl->mem_size >> PAGE_SHIFT)
+ return -EINVAL;
+
+ /* ast2400/2500 AHB accesses are not cache coherent */
--- /dev/null
+From a89f355e469dcda129c2522be4fdba00c1c74c83 Mon Sep 17 00:00:00 2001
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Date: Tue, 29 Jun 2021 21:02:49 +0530
+Subject: soc: qcom: aoss: Fix the out of bound usage of cooling_devs
+
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+commit a89f355e469dcda129c2522be4fdba00c1c74c83 upstream.
+
+In "qmp_cooling_devices_register", the count value is initially
+QMP_NUM_COOLING_RESOURCES, which is 2. Based on the initial count value,
+the memory for cooling_devs is allocated. Then while calling the
+"qmp_cooling_device_add" function, count value is post-incremented for
+each child node.
+
+This makes the out of bound access to the cooling_dev array. Fix it by
+passing the QMP_NUM_COOLING_RESOURCES definition to devm_kzalloc() and
+initializing the count to 0.
+
+While at it, let's also free the memory allocated to cooling_dev if no
+cooling device is found in DT and during unroll phase.
+
+Cc: stable@vger.kernel.org # 5.4
+Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.")
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Link: https://lore.kernel.org/r/20210629153249.73428-1-manivannan.sadhasivam@linaro.org
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/qcom/qcom_aoss.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/soc/qcom/qcom_aoss.c
++++ b/drivers/soc/qcom/qcom_aoss.c
+@@ -472,12 +472,12 @@ static int qmp_cooling_device_add(struct
+ static int qmp_cooling_devices_register(struct qmp *qmp)
+ {
+ struct device_node *np, *child;
+- int count = QMP_NUM_COOLING_RESOURCES;
++ int count = 0;
+ int ret;
+
+ np = qmp->dev->of_node;
+
+- qmp->cooling_devs = devm_kcalloc(qmp->dev, count,
++ qmp->cooling_devs = devm_kcalloc(qmp->dev, QMP_NUM_COOLING_RESOURCES,
+ sizeof(*qmp->cooling_devs),
+ GFP_KERNEL);
+
+@@ -493,12 +493,16 @@ static int qmp_cooling_devices_register(
+ goto unroll;
+ }
+
++ if (!count)
++ devm_kfree(qmp->dev, qmp->cooling_devs);
++
+ return 0;
+
+ unroll:
+ while (--count >= 0)
+ thermal_cooling_device_unregister
+ (qmp->cooling_devs[count].cdev);
++ devm_kfree(qmp->dev, qmp->cooling_devs);
+
+ return ret;
+ }
--- /dev/null
+From b5f7912bb604b47a0fe024560488a7556dce8ee7 Mon Sep 17 00:00:00 2001
+From: Rolf Eike Beer <eb@emlix.com>
+Date: Fri, 30 Jul 2021 13:51:54 +0200
+Subject: tools/thermal/tmon: Add cross compiling support
+
+From: Rolf Eike Beer <eb@emlix.com>
+
+commit b5f7912bb604b47a0fe024560488a7556dce8ee7 upstream.
+
+Default to prefixed pkg-config when crosscompiling, this matches what
+other parts of the tools/ directory already do.
+
+[dlezcano] : Reworked description
+
+Signed-off-by: Rolf Eike Beer <eb@emlix.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/31302992.qZodDJZGDc@devpool47
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/thermal/tmon/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/thermal/tmon/Makefile
++++ b/tools/thermal/tmon/Makefile
+@@ -10,7 +10,7 @@ override CFLAGS+= $(call cc-option,-O3,-
+ # Add "-fstack-protector" only if toolchain supports it.
+ override CFLAGS+= $(call cc-option,-fstack-protector-strong)
+ CC?= $(CROSS_COMPILE)gcc
+-PKG_CONFIG?= pkg-config
++PKG_CONFIG?= $(CROSS_COMPILE)pkg-config
+
+ override CFLAGS+=-D VERSION=\"$(VERSION)\"
+ LDFLAGS+=
--- /dev/null
+From a30dc6cf0dc51419021550152e435736aaef8799 Mon Sep 17 00:00:00 2001
+From: Wang Hai <wanghai38@huawei.com>
+Date: Wed, 18 Aug 2021 20:48:45 +0800
+Subject: VMCI: fix NULL pointer dereference when unmapping queue pair
+
+From: Wang Hai <wanghai38@huawei.com>
+
+commit a30dc6cf0dc51419021550152e435736aaef8799 upstream.
+
+I got a NULL pointer dereference report when doing fuzz test:
+
+Call Trace:
+ qp_release_pages+0xae/0x130
+ qp_host_unregister_user_memory.isra.25+0x2d/0x80
+ vmci_qp_broker_unmap+0x191/0x320
+ ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0
+ vmci_host_unlocked_ioctl+0x59f/0xd50
+ ? do_vfs_ioctl+0x14b/0xa10
+ ? tomoyo_file_ioctl+0x28/0x30
+ ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0
+ __x64_sys_ioctl+0xea/0x120
+ do_syscall_64+0x34/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+When a queue pair is created by the following call, it will not
+register the user memory if the page_store is NULL, and the
+entry->state will be set to VMCIQPB_CREATED_NO_MEM.
+
+vmci_host_unlocked_ioctl
+ vmci_host_do_alloc_queuepair
+ vmci_qp_broker_alloc
+ qp_broker_alloc
+ qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM;
+
+When unmapping this queue pair, qp_host_unregister_user_memory() will
+be called to unregister the non-existent user memory, which will
+result in a null pointer reference. It will also change
+VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be
+present in this operation.
+
+Only when the qp broker has mem, it can unregister the user
+memory when unmapping the qp broker.
+
+Only when the qp broker has no mem, it can register the user
+memory when mapping the qp broker.
+
+Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
+Signed-off-by: Wang Hai <wanghai38@huawei.com>
+Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_queue_pair.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
+@@ -2238,7 +2238,8 @@ int vmci_qp_broker_map(struct vmci_handl
+
+ result = VMCI_SUCCESS;
+
+- if (context_id != VMCI_HOST_CONTEXT_ID) {
++ if (context_id != VMCI_HOST_CONTEXT_ID &&
++ !QPBROKERSTATE_HAS_MEM(entry)) {
+ struct vmci_qp_page_store page_store;
+
+ page_store.pages = guest_mem;
+@@ -2345,7 +2346,8 @@ int vmci_qp_broker_unmap(struct vmci_han
+ goto out;
+ }
+
+- if (context_id != VMCI_HOST_CONTEXT_ID) {
++ if (context_id != VMCI_HOST_CONTEXT_ID &&
++ QPBROKERSTATE_HAS_MEM(entry)) {
+ qp_acquire_queue_mutex(entry->produce_q);
+ result = qp_save_headers(entry);
+ if (result < VMCI_SUCCESS)
projects / thirdparty / kernel / stable-queue.git / commitdiff
