--- /dev/null
+From 8468f45091d2866affed6f6a7aecc20779139173 Mon Sep 17 00:00:00 2001
+From: Coly Li <colyli@suse.de>
+Date: Wed, 3 Nov 2021 14:49:17 +0800
+Subject: bcache: fix use-after-free problem in bcache_device_free()
+
+From: Coly Li <colyli@suse.de>
+
+commit 8468f45091d2866affed6f6a7aecc20779139173 upstream.
+
+In bcache_device_free(), pointer disk is referenced still in
+ida_simple_remove() after blk_cleanup_disk() gets called on this
+pointer. This may cause a potential panic by use-after-free on the
+disk pointer.
+
+This patch fixes the problem by calling blk_cleanup_disk() after
+ida_simple_remove().
+
+Fixes: bc70852fd104 ("bcache: convert to blk_alloc_disk/blk_cleanup_disk")
+Signed-off-by: Coly Li <colyli@suse.de>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Hannes Reinecke <hare@suse.de>
+Cc: Ulf Hansson <ulf.hansson@linaro.org>
+Cc: stable@vger.kernel.org # v5.14+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20211103064917.67383-1-colyli@suse.de
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/bcache/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/bcache/super.c
++++ b/drivers/md/bcache/super.c
+@@ -885,9 +885,9 @@ static void bcache_device_free(struct bc
+ bcache_device_detach(d);
+
+ if (disk) {
+- blk_cleanup_disk(disk);
+ ida_simple_remove(&bcache_device_idx,
+ first_minor_to_idx(disk->first_minor));
++ blk_cleanup_disk(disk);
+ }
+
+ bioset_exit(&d->bio_split);
--- /dev/null
+From 2878feaed543c35f9dbbe6d8ce36fb67ac803eef Mon Sep 17 00:00:00 2001
+From: Coly Li <colyli@suse.de>
+Date: Wed, 3 Nov 2021 23:10:41 +0800
+Subject: bcache: Revert "bcache: use bvec_virt"
+
+From: Coly Li <colyli@suse.de>
+
+commit 2878feaed543c35f9dbbe6d8ce36fb67ac803eef upstream.
+
+This reverts commit 2fd3e5efe791946be0957c8e1eed9560b541fe46.
+
+The above commit replaces page_address(bv->bv_page) by bvec_virt(bv) to
+avoid directly access to bv->bv_page, but in situation bv->bv_offset is
+not zero and page_address(bv->bv_page) is not equal to bvec_virt(bv). In
+such case a memory corruption may happen because memory in next page is
+tainted by following line in do_btree_node_write(),
+ memcpy(bvec_virt(bv), addr, PAGE_SIZE);
+
+This patch reverts the mentioned commit to avoid the memory corruption.
+
+Fixes: 2fd3e5efe791 ("bcache: use bvec_virt")
+Signed-off-by: Coly Li <colyli@suse.de>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: stable@vger.kernel.org # 5.15
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20211103151041.70516-1-colyli@suse.de
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/bcache/btree.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/bcache/btree.c
++++ b/drivers/md/bcache/btree.c
+@@ -378,7 +378,7 @@ static void do_btree_node_write(struct b
+ struct bvec_iter_all iter_all;
+
+ bio_for_each_segment_all(bv, b->bio, iter_all) {
+- memcpy(bvec_virt(bv), addr, PAGE_SIZE);
++ memcpy(page_address(bv->bv_page), addr, PAGE_SIZE);
+ addr += PAGE_SIZE;
+ }
+
--- /dev/null
+From 313c84b5ae4104e48c661d5d706f9f4c425fd50f Mon Sep 17 00:00:00 2001
+From: Jack Andersen <jackoalan@gmail.com>
+Date: Mon, 18 Oct 2021 13:25:41 +0200
+Subject: mfd: dln2: Add cell for initializing DLN2 ADC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jack Andersen <jackoalan@gmail.com>
+
+commit 313c84b5ae4104e48c661d5d706f9f4c425fd50f upstream.
+
+This patch extends the DLN2 driver; adding cell for adc_dln2 module.
+
+The original patch[1] fell through the cracks when the driver was added
+so ADC has never actually been usable. That patch did not have ACPI
+support which was added in v5.9, so the oldest supported version this
+current patch can be backported to is 5.10.
+
+[1] https://www.spinics.net/lists/linux-iio/msg33975.html
+
+Cc: <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Jack Andersen <jackoalan@gmail.com>
+Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Link: https://lore.kernel.org/r/20211018112541.25466-1-noralf@tronnes.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/dln2.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/mfd/dln2.c
++++ b/drivers/mfd/dln2.c
+@@ -50,6 +50,7 @@ enum dln2_handle {
+ DLN2_HANDLE_GPIO,
+ DLN2_HANDLE_I2C,
+ DLN2_HANDLE_SPI,
++ DLN2_HANDLE_ADC,
+ DLN2_HANDLES
+ };
+
+@@ -653,6 +654,7 @@ enum {
+ DLN2_ACPI_MATCH_GPIO = 0,
+ DLN2_ACPI_MATCH_I2C = 1,
+ DLN2_ACPI_MATCH_SPI = 2,
++ DLN2_ACPI_MATCH_ADC = 3,
+ };
+
+ static struct dln2_platform_data dln2_pdata_gpio = {
+@@ -683,6 +685,16 @@ static struct mfd_cell_acpi_match dln2_a
+ .adr = DLN2_ACPI_MATCH_SPI,
+ };
+
++/* Only one ADC port supported */
++static struct dln2_platform_data dln2_pdata_adc = {
++ .handle = DLN2_HANDLE_ADC,
++ .port = 0,
++};
++
++static struct mfd_cell_acpi_match dln2_acpi_match_adc = {
++ .adr = DLN2_ACPI_MATCH_ADC,
++};
++
+ static const struct mfd_cell dln2_devs[] = {
+ {
+ .name = "dln2-gpio",
+@@ -702,6 +714,12 @@ static const struct mfd_cell dln2_devs[]
+ .platform_data = &dln2_pdata_spi,
+ .pdata_size = sizeof(struct dln2_platform_data),
+ },
++ {
++ .name = "dln2-adc",
++ .acpi_match = &dln2_acpi_match_adc,
++ .platform_data = &dln2_pdata_adc,
++ .pdata_size = sizeof(struct dln2_platform_data),
++ },
+ };
+
+ static void dln2_stop(struct dln2_dev *dln2)
--- /dev/null
+From 60e2793d440a3ec95abb5d6d4fc034a4b480472d Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Fri, 5 Nov 2021 13:38:06 -0700
+Subject: mm, oom: do not trigger out_of_memory from the #PF
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream.
+
+Any allocation failure during the #PF path will return with VM_FAULT_OOM
+which in turn results in pagefault_out_of_memory. This can happen for 2
+different reasons. a) Memcg is out of memory and we rely on
+mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
+normal allocation fails.
+
+The latter is quite problematic because allocation paths already trigger
+out_of_memory and the page allocator tries really hard to not fail
+allocations. Anyway, if the OOM killer has been already invoked there
+is no reason to invoke it again from the #PF path. Especially when the
+OOM condition might be gone by that time and we have no way to find out
+other than allocate.
+
+Moreover if the allocation failed and the OOM killer hasn't been invoked
+then we are unlikely to do the right thing from the #PF context because
+we have already lost the allocation context and restictions and
+therefore might oom kill a task from a different NUMA domain.
+
+This all suggests that there is no legitimate reason to trigger
+out_of_memory from pagefault_out_of_memory so drop it. Just to be sure
+that no #PF path returns with VM_FAULT_OOM without allocation print a
+warning that this is happening before we restart the #PF.
+
+[VvS: #PF allocation can hit into limit of cgroup v1 kmem controller.
+This is a local problem related to memcg, however, it causes unnecessary
+global OOM kills that are repeated over and over again and escalate into a
+real disaster. This has been broken since kmem accounting has been
+introduced for cgroup v1 (3.8). There was no kmem specific reclaim for
+the separate limit so the only way to handle kmem hard limit was to return
+with ENOMEM. In upstream the problem will be fixed by removing the
+outdated kmem limit, however stable and LTS kernels cannot do it and are
+still affected. This patch fixes the problem and should be backported
+into stable/LTS.]
+
+Link: https://lkml.kernel.org/r/f5fd8dd8-0ad4-c524-5f65-920b01972a42@virtuozzo.com
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Cc: Uladzislau Rezki <urezki@gmail.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/oom_kill.c | 22 ++++++++--------------
+ 1 file changed, 8 insertions(+), 14 deletions(-)
+
+--- a/mm/oom_kill.c
++++ b/mm/oom_kill.c
+@@ -1120,19 +1120,15 @@ bool out_of_memory(struct oom_control *o
+ }
+
+ /*
+- * The pagefault handler calls here because it is out of memory, so kill a
+- * memory-hogging task. If oom_lock is held by somebody else, a parallel oom
+- * killing is already in progress so do nothing.
++ * The pagefault handler calls here because some allocation has failed. We have
++ * to take care of the memcg OOM here because this is the only safe context without
++ * any locks held but let the oom killer triggered from the allocation context care
++ * about the global OOM.
+ */
+ void pagefault_out_of_memory(void)
+ {
+- struct oom_control oc = {
+- .zonelist = NULL,
+- .nodemask = NULL,
+- .memcg = NULL,
+- .gfp_mask = 0,
+- .order = 0,
+- };
++ static DEFINE_RATELIMIT_STATE(pfoom_rs, DEFAULT_RATELIMIT_INTERVAL,
++ DEFAULT_RATELIMIT_BURST);
+
+ if (mem_cgroup_oom_synchronize(true))
+ return;
+@@ -1140,10 +1136,8 @@ void pagefault_out_of_memory(void)
+ if (fatal_signal_pending(current))
+ return;
+
+- if (!mutex_trylock(&oom_lock))
+- return;
+- out_of_memory(&oc);
+- mutex_unlock(&oom_lock);
++ if (__ratelimit(&pfoom_rs))
++ pr_warn("Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF\n");
+ }
+
+ SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
--- /dev/null
+From 0b28179a6138a5edd9d82ad2687c05b3773c387b Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Fri, 5 Nov 2021 13:38:02 -0700
+Subject: mm, oom: pagefault_out_of_memory: don't force global OOM for dying tasks
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit 0b28179a6138a5edd9d82ad2687c05b3773c387b upstream.
+
+Patch series "memcg: prohibit unconditional exceeding the limit of dying tasks", v3.
+
+Memory cgroup charging allows killed or exiting tasks to exceed the hard
+limit. It can be misused and allowed to trigger global OOM from inside
+a memcg-limited container. On the other hand if memcg fails allocation,
+called from inside #PF handler it triggers global OOM from inside
+pagefault_out_of_memory().
+
+To prevent these problems this patchset:
+ (a) removes execution of out_of_memory() from
+ pagefault_out_of_memory(), becasue nobody can explain why it is
+ necessary.
+ (b) allow memcg to fail allocation of dying/killed tasks.
+
+This patch (of 3):
+
+Any allocation failure during the #PF path will return with VM_FAULT_OOM
+which in turn results in pagefault_out_of_memory which in turn executes
+out_out_memory() and can kill a random task.
+
+An allocation might fail when the current task is the oom victim and
+there are no memory reserves left. The OOM killer is already handled at
+the page allocator level for the global OOM and at the charging level
+for the memcg one. Both have much more information about the scope of
+allocation/charge request. This means that either the OOM killer has
+been invoked properly and didn't lead to the allocation success or it
+has been skipped because it couldn't have been invoked. In both cases
+triggering it from here is pointless and even harmful.
+
+It makes much more sense to let the killed task die rather than to wake
+up an eternally hungry oom-killer and send him to choose a fatter victim
+for breakfast.
+
+Link: https://lkml.kernel.org/r/0828a149-786e-7c06-b70a-52d086818ea3@virtuozzo.com
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Suggested-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Cc: Uladzislau Rezki <urezki@gmail.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/oom_kill.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/oom_kill.c
++++ b/mm/oom_kill.c
+@@ -1137,6 +1137,9 @@ void pagefault_out_of_memory(void)
+ if (mem_cgroup_oom_synchronize(true))
+ return;
+
++ if (fatal_signal_pending(current))
++ return;
++
+ if (!mutex_trylock(&oom_lock))
+ return;
+ out_of_memory(&oc);
--- /dev/null
+From 8468e937df1f31411d1e127fa38db064af051fe5 Mon Sep 17 00:00:00 2001
+From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+Date: Fri, 5 Nov 2021 13:43:44 -0700
+Subject: mm, thp: fix incorrect unmap behavior for private pages
+
+From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+
+commit 8468e937df1f31411d1e127fa38db064af051fe5 upstream.
+
+When truncating pagecache on file THP, the private pages of a process
+should not be unmapped mapping. This incorrect behavior on a dynamic
+shared libraries which will cause related processes to happen core dump.
+
+A simple test for a DSO (Prerequisite is the DSO mapped in file THP):
+
+ int main(int argc, char *argv[])
+ {
+ int fd;
+
+ fd = open(argv[1], O_WRONLY);
+ if (fd < 0) {
+ perror("open");
+ }
+
+ close(fd);
+ return 0;
+ }
+
+The test only to open a target DSO, and do nothing. But this operation
+will lead one or more process to happen core dump. This patch mainly to
+fix this bug.
+
+Link: https://lkml.kernel.org/r/20211025092134.18562-3-rongwei.wang@linux.alibaba.com
+Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
+Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+Tested-by: Xu Yu <xuyu@linux.alibaba.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Song Liu <song@kernel.org>
+Cc: William Kucharski <william.kucharski@oracle.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Yang Shi <shy828301@gmail.com>
+Cc: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: Collin Fijalkovich <cfijalkovich@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/open.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/fs/open.c
++++ b/fs/open.c
+@@ -857,8 +857,17 @@ static int do_dentry_open(struct file *f
+ */
+ smp_mb();
+ if (filemap_nr_thps(inode->i_mapping)) {
++ struct address_space *mapping = inode->i_mapping;
++
+ filemap_invalidate_lock(inode->i_mapping);
+- truncate_pagecache(inode, 0);
++ /*
++ * unmap_mapping_range just need to be called once
++ * here, because the private pages is not need to be
++ * unmapped mapping (e.g. data segment of dynamic
++ * shared libraries here).
++ */
++ unmap_mapping_range(mapping, 0, 0, 0);
++ truncate_inode_pages(mapping, 0);
+ filemap_invalidate_unlock(inode->i_mapping);
+ }
+ }
--- /dev/null
+From 55fc0d91746759c71bc165bba62a2db64ac98e35 Mon Sep 17 00:00:00 2001
+From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+Date: Fri, 5 Nov 2021 13:43:41 -0700
+Subject: mm, thp: lock filemap when truncating page cache
+
+From: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+
+commit 55fc0d91746759c71bc165bba62a2db64ac98e35 upstream.
+
+Patch series "fix two bugs for file THP".
+
+This patch (of 2):
+
+Transparent huge page has supported read-only non-shmem files. The
+file- backed THP is collapsed by khugepaged and truncated when written
+(for shared libraries).
+
+However, there is a race when multiple writers truncate the same page
+cache concurrently.
+
+In that case, subpage(s) of file THP can be revealed by find_get_entry
+in truncate_inode_pages_range, which will trigger PageTail BUG_ON in
+truncate_inode_page, as follows:
+
+ page:000000009e420ff2 refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff pfn:0x50c3ff
+ head:0000000075ff816d order:9 compound_mapcount:0 compound_pincount:0
+ flags: 0x37fffe0000010815(locked|uptodate|lru|arch_1|head)
+ raw: 37fffe0000000000 fffffe0013108001 dead000000000122 dead000000000400
+ raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
+ head: 37fffe0000010815 fffffe001066bd48 ffff000404183c20 0000000000000000
+ head: 0000000000000600 0000000000000000 00000001ffffffff ffff000c0345a000
+ page dumped because: VM_BUG_ON_PAGE(PageTail(page))
+ ------------[ cut here ]------------
+ kernel BUG at mm/truncate.c:213!
+ Internal error: Oops - BUG: 0 [#1] SMP
+ Modules linked in: xfs(E) libcrc32c(E) rfkill(E) ...
+ CPU: 14 PID: 11394 Comm: check_madvise_d Kdump: ...
+ Hardware name: ECS, BIOS 0.0.0 02/06/2015
+ pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
+ Call trace:
+ truncate_inode_page+0x64/0x70
+ truncate_inode_pages_range+0x550/0x7e4
+ truncate_pagecache+0x58/0x80
+ do_dentry_open+0x1e4/0x3c0
+ vfs_open+0x38/0x44
+ do_open+0x1f0/0x310
+ path_openat+0x114/0x1dc
+ do_filp_open+0x84/0x134
+ do_sys_openat2+0xbc/0x164
+ __arm64_sys_openat+0x74/0xc0
+ el0_svc_common.constprop.0+0x88/0x220
+ do_el0_svc+0x30/0xa0
+ el0_svc+0x20/0x30
+ el0_sync_handler+0x1a4/0x1b0
+ el0_sync+0x180/0x1c0
+ Code: aa0103e0 900061e1 910ec021 9400d300 (d4210000)
+
+This patch mainly to lock filemap when one enter truncate_pagecache(),
+avoiding truncating the same page cache concurrently.
+
+Link: https://lkml.kernel.org/r/20211025092134.18562-1-rongwei.wang@linux.alibaba.com
+Link: https://lkml.kernel.org/r/20211025092134.18562-2-rongwei.wang@linux.alibaba.com
+Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
+Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
+Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
+Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Tested-by: Song Liu <song@kernel.org>
+Cc: Collin Fijalkovich <cfijalkovich@google.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: William Kucharski <william.kucharski@oracle.com>
+Cc: Yang Shi <shy828301@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/open.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/fs/open.c
++++ b/fs/open.c
+@@ -856,8 +856,11 @@ static int do_dentry_open(struct file *f
+ * of THPs into the page cache will fail.
+ */
+ smp_mb();
+- if (filemap_nr_thps(inode->i_mapping))
++ if (filemap_nr_thps(inode->i_mapping)) {
++ filemap_invalidate_lock(inode->i_mapping);
+ truncate_pagecache(inode, 0);
++ filemap_invalidate_unlock(inode->i_mapping);
++ }
+ }
+
+ return 0;
--- /dev/null
+From 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 4 Nov 2021 18:26:26 +0100
+Subject: PM: sleep: Avoid calling put_device() under dpm_list_mtx
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 upstream.
+
+It is generally unsafe to call put_device() with dpm_list_mtx held,
+because the given device's release routine may carry out an action
+depending on that lock which then may deadlock, so modify the
+system-wide suspend and resume of devices to always drop dpm_list_mtx
+before calling put_device() (and adjust white space somewhat while
+at it).
+
+For instance, this prevents the following splat from showing up in
+the kernel log after a system resume in certain configurations:
+
+[ 3290.969514] ======================================================
+[ 3290.969517] WARNING: possible circular locking dependency detected
+[ 3290.969519] 5.15.0+ #2420 Tainted: G S
+[ 3290.969523] ------------------------------------------------------
+[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
+[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
+[ 3290.969554]
+ but task is already holding lock:
+[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
+[ 3290.969571]
+ which lock already depends on the new lock.
+
+[ 3290.969573]
+ the existing dependency chain (in reverse order) is:
+[ 3290.969575]
+ -> #3 (dpm_list_mtx){+.+.}-{3:3}:
+[ 3290.969583] __mutex_lock+0x9d/0xa30
+[ 3290.969591] device_pm_add+0x2e/0xe0
+[ 3290.969597] device_add+0x4d5/0x8f0
+[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
+[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
+[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
+[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
+[ 3290.969842] process_one_work+0x2aa/0x650
+[ 3290.969851] worker_thread+0x39/0x400
+[ 3290.969859] kthread+0x142/0x170
+[ 3290.969865] ret_from_fork+0x22/0x30
+[ 3290.969872]
+ -> #2 (&hdev->lock){+.+.}-{3:3}:
+[ 3290.969881] __mutex_lock+0x9d/0xa30
+[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
+[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
+[ 3290.969978] process_one_work+0x2aa/0x650
+[ 3290.969985] worker_thread+0x39/0x400
+[ 3290.969993] kthread+0x142/0x170
+[ 3290.969999] ret_from_fork+0x22/0x30
+[ 3290.970004]
+ -> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
+[ 3290.970013] process_one_work+0x27d/0x650
+[ 3290.970020] worker_thread+0x39/0x400
+[ 3290.970028] kthread+0x142/0x170
+[ 3290.970033] ret_from_fork+0x22/0x30
+[ 3290.970038]
+ -> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
+[ 3290.970047] __lock_acquire+0x15cb/0x1b50
+[ 3290.970054] lock_acquire+0x26c/0x300
+[ 3290.970059] flush_workqueue+0xae/0x4a0
+[ 3290.970066] drain_workqueue+0xa1/0x130
+[ 3290.970073] destroy_workqueue+0x34/0x1f0
+[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
+[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
+[ 3290.970195] device_release+0x33/0x90
+[ 3290.970201] kobject_release+0x63/0x160
+[ 3290.970211] dpm_resume+0x164/0x3e0
+[ 3290.970215] dpm_resume_end+0xd/0x20
+[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
+[ 3290.970229] pm_suspend+0x26b/0x310
+[ 3290.970236] state_store+0x42/0x90
+[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
+[ 3290.970251] new_sync_write+0x125/0x1c0
+[ 3290.970257] vfs_write+0x360/0x3c0
+[ 3290.970263] ksys_write+0xa7/0xe0
+[ 3290.970269] do_syscall_64+0x3a/0x80
+[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
+[ 3290.970284]
+ other info that might help us debug this:
+
+[ 3290.970285] Chain exists of:
+ (wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
+
+[ 3290.970297] Possible unsafe locking scenario:
+
+[ 3290.970299] CPU0 CPU1
+[ 3290.970300] ---- ----
+[ 3290.970302] lock(dpm_list_mtx);
+[ 3290.970306] lock(&hdev->lock);
+[ 3290.970310] lock(dpm_list_mtx);
+[ 3290.970314] lock((wq_completion)hci0#2);
+[ 3290.970319]
+ *** DEADLOCK ***
+
+[ 3290.970321] 7 locks held by systemd-sleep/4553:
+[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
+[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
+[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
+[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
+[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
+[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
+[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
+[ 3290.970428]
+ stack backtrace:
+[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
+[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
+[ 3290.970441] Call Trace:
+[ 3290.970446] dump_stack_lvl+0x44/0x57
+[ 3290.970454] check_noncircular+0x105/0x120
+[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
+[ 3290.970474] __lock_acquire+0x15cb/0x1b50
+[ 3290.970487] lock_acquire+0x26c/0x300
+[ 3290.970493] ? flush_workqueue+0x87/0x4a0
+[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
+[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
+[ 3290.970519] flush_workqueue+0xae/0x4a0
+[ 3290.970526] ? flush_workqueue+0x87/0x4a0
+[ 3290.970544] ? drain_workqueue+0xa1/0x130
+[ 3290.970552] drain_workqueue+0xa1/0x130
+[ 3290.970561] destroy_workqueue+0x34/0x1f0
+[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
+[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
+[ 3290.970687] device_release+0x33/0x90
+[ 3290.970695] kobject_release+0x63/0x160
+[ 3290.970705] dpm_resume+0x164/0x3e0
+[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
+[ 3290.970718] dpm_resume_end+0xd/0x20
+[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
+[ 3290.970737] pm_suspend+0x26b/0x310
+[ 3290.970746] state_store+0x42/0x90
+[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
+[ 3290.970764] new_sync_write+0x125/0x1c0
+[ 3290.970777] vfs_write+0x360/0x3c0
+[ 3290.970785] ksys_write+0xa7/0xe0
+[ 3290.970794] do_syscall_64+0x3a/0x80
+[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
+[ 3290.970811] RIP: 0033:0x7f41b1328164
+[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
+[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
+[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
+[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
+[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
+[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
+
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/power/main.c | 84 +++++++++++++++++++++++++++++++---------------
+ 1 file changed, 57 insertions(+), 27 deletions(-)
+
+--- a/drivers/base/power/main.c
++++ b/drivers/base/power/main.c
+@@ -711,6 +711,7 @@ static void dpm_noirq_resume_devices(pm_
+ dev = to_device(dpm_noirq_list.next);
+ get_device(dev);
+ list_move_tail(&dev->power.entry, &dpm_late_early_list);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ if (!is_async(dev)) {
+@@ -725,8 +726,9 @@ static void dpm_noirq_resume_devices(pm_
+ }
+ }
+
+- mutex_lock(&dpm_list_mtx);
+ put_device(dev);
++
++ mutex_lock(&dpm_list_mtx);
+ }
+ mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
+@@ -852,6 +854,7 @@ void dpm_resume_early(pm_message_t state
+ dev = to_device(dpm_late_early_list.next);
+ get_device(dev);
+ list_move_tail(&dev->power.entry, &dpm_suspended_list);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ if (!is_async(dev)) {
+@@ -865,8 +868,10 @@ void dpm_resume_early(pm_message_t state
+ pm_dev_err(dev, state, " early", error);
+ }
+ }
+- mutex_lock(&dpm_list_mtx);
++
+ put_device(dev);
++
++ mutex_lock(&dpm_list_mtx);
+ }
+ mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
+@@ -1029,7 +1034,12 @@ void dpm_resume(pm_message_t state)
+ }
+ if (!list_empty(&dev->power.entry))
+ list_move_tail(&dev->power.entry, &dpm_prepared_list);
++
++ mutex_unlock(&dpm_list_mtx);
++
+ put_device(dev);
++
++ mutex_lock(&dpm_list_mtx);
+ }
+ mutex_unlock(&dpm_list_mtx);
+ async_synchronize_full();
+@@ -1107,14 +1117,16 @@ void dpm_complete(pm_message_t state)
+ get_device(dev);
+ dev->power.is_prepared = false;
+ list_move(&dev->power.entry, &list);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ trace_device_pm_callback_start(dev, "", state.event);
+ device_complete(dev, state);
+ trace_device_pm_callback_end(dev, 0);
+
+- mutex_lock(&dpm_list_mtx);
+ put_device(dev);
++
++ mutex_lock(&dpm_list_mtx);
+ }
+ list_splice(&list, &dpm_list);
+ mutex_unlock(&dpm_list_mtx);
+@@ -1299,17 +1311,21 @@ static int dpm_noirq_suspend_devices(pm_
+ error = device_suspend_noirq(dev);
+
+ mutex_lock(&dpm_list_mtx);
++
+ if (error) {
+ pm_dev_err(dev, state, " noirq", error);
+ dpm_save_failed_dev(dev_name(dev));
+- put_device(dev);
+- break;
+- }
+- if (!list_empty(&dev->power.entry))
++ } else if (!list_empty(&dev->power.entry)) {
+ list_move(&dev->power.entry, &dpm_noirq_list);
++ }
++
++ mutex_unlock(&dpm_list_mtx);
++
+ put_device(dev);
+
+- if (async_error)
++ mutex_lock(&dpm_list_mtx);
++
++ if (error || async_error)
+ break;
+ }
+ mutex_unlock(&dpm_list_mtx);
+@@ -1476,23 +1492,28 @@ int dpm_suspend_late(pm_message_t state)
+ struct device *dev = to_device(dpm_suspended_list.prev);
+
+ get_device(dev);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ error = device_suspend_late(dev);
+
+ mutex_lock(&dpm_list_mtx);
++
+ if (!list_empty(&dev->power.entry))
+ list_move(&dev->power.entry, &dpm_late_early_list);
+
+ if (error) {
+ pm_dev_err(dev, state, " late", error);
+ dpm_save_failed_dev(dev_name(dev));
+- put_device(dev);
+- break;
+ }
++
++ mutex_unlock(&dpm_list_mtx);
++
+ put_device(dev);
+
+- if (async_error)
++ mutex_lock(&dpm_list_mtx);
++
++ if (error || async_error)
+ break;
+ }
+ mutex_unlock(&dpm_list_mtx);
+@@ -1752,21 +1773,27 @@ int dpm_suspend(pm_message_t state)
+ struct device *dev = to_device(dpm_prepared_list.prev);
+
+ get_device(dev);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ error = device_suspend(dev);
+
+ mutex_lock(&dpm_list_mtx);
++
+ if (error) {
+ pm_dev_err(dev, state, "", error);
+ dpm_save_failed_dev(dev_name(dev));
+- put_device(dev);
+- break;
+- }
+- if (!list_empty(&dev->power.entry))
++ } else if (!list_empty(&dev->power.entry)) {
+ list_move(&dev->power.entry, &dpm_suspended_list);
++ }
++
++ mutex_unlock(&dpm_list_mtx);
++
+ put_device(dev);
+- if (async_error)
++
++ mutex_lock(&dpm_list_mtx);
++
++ if (error || async_error)
+ break;
+ }
+ mutex_unlock(&dpm_list_mtx);
+@@ -1883,6 +1910,7 @@ int dpm_prepare(pm_message_t state)
+ struct device *dev = to_device(dpm_list.next);
+
+ get_device(dev);
++
+ mutex_unlock(&dpm_list_mtx);
+
+ trace_device_pm_callback_start(dev, "", state.event);
+@@ -1890,21 +1918,23 @@ int dpm_prepare(pm_message_t state)
+ trace_device_pm_callback_end(dev, error);
+
+ mutex_lock(&dpm_list_mtx);
+- if (error) {
+- if (error == -EAGAIN) {
+- put_device(dev);
+- error = 0;
+- continue;
+- }
++
++ if (!error) {
++ dev->power.is_prepared = true;
++ if (!list_empty(&dev->power.entry))
++ list_move_tail(&dev->power.entry, &dpm_prepared_list);
++ } else if (error == -EAGAIN) {
++ error = 0;
++ } else {
+ dev_info(dev, "not prepared for power transition: code %d\n",
+ error);
+- put_device(dev);
+- break;
+ }
+- dev->power.is_prepared = true;
+- if (!list_empty(&dev->power.entry))
+- list_move_tail(&dev->power.entry, &dpm_prepared_list);
++
++ mutex_unlock(&dpm_list_mtx);
++
+ put_device(dev);
++
++ mutex_lock(&dpm_list_mtx);
+ }
+ mutex_unlock(&dpm_list_mtx);
+ trace_suspend_resume(TPS("dpm_prepare"), state.event, false);
--- /dev/null
+From 24acbd9dc934f5d9418a736c532d3970a272063e Mon Sep 17 00:00:00 2001
+From: Peng Fan <peng.fan@nxp.com>
+Date: Fri, 10 Sep 2021 17:06:16 +0800
+Subject: remoteproc: elf_loader: Fix loading segment when is_iomem true
+
+From: Peng Fan <peng.fan@nxp.com>
+
+commit 24acbd9dc934f5d9418a736c532d3970a272063e upstream.
+
+It seems luckliy work on i.MX platform, but it is wrong.
+Need use memcpy_toio, not memcpy_fromio.
+
+Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va")
+Tested-by: Dong Aisheng <aisheng.dong@nxp.com> (i.MX8MQ)
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210910090621.3073540-2-peng.fan@oss.nxp.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/remoteproc/remoteproc_elf_loader.c
++++ b/drivers/remoteproc/remoteproc_elf_loader.c
+@@ -220,7 +220,7 @@ int rproc_elf_load_segments(struct rproc
+ /* put the segment where the remote processor expects it */
+ if (filesz) {
+ if (is_iomem)
+- memcpy_fromio(ptr, (void __iomem *)(elf_data + offset), filesz);
++ memcpy_toio((void __iomem *)ptr, elf_data + offset, filesz);
+ else
+ memcpy(ptr, elf_data + offset, filesz);
+ }
--- /dev/null
+From 970675f61bf5761d7e5326f6e4df995ecdba5e11 Mon Sep 17 00:00:00 2001
+From: Dong Aisheng <aisheng.dong@nxp.com>
+Date: Fri, 10 Sep 2021 17:06:17 +0800
+Subject: remoteproc: Fix the wrong default value of is_iomem
+
+From: Dong Aisheng <aisheng.dong@nxp.com>
+
+commit 970675f61bf5761d7e5326f6e4df995ecdba5e11 upstream.
+
+Currently the is_iomem is a random value in the stack which may
+be default to true even on those platforms that not use iomem to
+store firmware.
+
+Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
+Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
+Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va")
+Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210910090621.3073540-3-peng.fan@oss.nxp.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/remoteproc_coredump.c | 2 +-
+ drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/remoteproc/remoteproc_coredump.c
++++ b/drivers/remoteproc/remoteproc_coredump.c
+@@ -152,8 +152,8 @@ static void rproc_copy_segment(struct rp
+ struct rproc_dump_segment *segment,
+ size_t offset, size_t size)
+ {
++ bool is_iomem = false;
+ void *ptr;
+- bool is_iomem;
+
+ if (segment->dump) {
+ segment->dump(rproc, segment, dest, offset, size);
+--- a/drivers/remoteproc/remoteproc_elf_loader.c
++++ b/drivers/remoteproc/remoteproc_elf_loader.c
+@@ -178,8 +178,8 @@ int rproc_elf_load_segments(struct rproc
+ u64 filesz = elf_phdr_get_p_filesz(class, phdr);
+ u64 offset = elf_phdr_get_p_offset(class, phdr);
+ u32 type = elf_phdr_get_p_type(class, phdr);
++ bool is_iomem = false;
+ void *ptr;
+- bool is_iomem;
+
+ if (type != PT_LOAD)
+ continue;
--- /dev/null
+From afe670e23af91d8a74a8d7049f6e0984bbf6ea11 Mon Sep 17 00:00:00 2001
+From: Dong Aisheng <aisheng.dong@nxp.com>
+Date: Fri, 10 Sep 2021 17:06:19 +0800
+Subject: remoteproc: imx_rproc: Fix ignoring mapping vdev regions
+
+From: Dong Aisheng <aisheng.dong@nxp.com>
+
+commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 upstream.
+
+vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and
+etc. Change to strncmp to cover them all.
+
+Fixes: 8f2d8961640f ("remoteproc: imx_rproc: ignore mapping vdev regions")
+Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210910090621.3073540-5-peng.fan@oss.nxp.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/imx_rproc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/remoteproc/imx_rproc.c
++++ b/drivers/remoteproc/imx_rproc.c
+@@ -582,8 +582,8 @@ static int imx_rproc_addr_init(struct im
+ struct resource res;
+
+ node = of_parse_phandle(np, "memory-region", a);
+- /* Not map vdev region */
+- if (!strcmp(node->name, "vdev"))
++ /* Not map vdevbuffer, vdevring region */
++ if (!strncmp(node->name, "vdev", strlen("vdev")))
+ continue;
+ err = of_address_to_resource(node, 0, &res);
+ if (err) {
--- /dev/null
+From e90547d59d4e29e269e22aa6ce590ed0b41207d2 Mon Sep 17 00:00:00 2001
+From: Dong Aisheng <aisheng.dong@nxp.com>
+Date: Fri, 10 Sep 2021 17:06:20 +0800
+Subject: remoteproc: imx_rproc: Fix rsc-table name
+
+From: Dong Aisheng <aisheng.dong@nxp.com>
+
+commit e90547d59d4e29e269e22aa6ce590ed0b41207d2 upstream.
+
+Usually the dash '-' is preferred in node name.
+So far, not dts in upstream kernel, so we just update node name
+in driver.
+
+Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
+Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
+Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel")
+Reviewed-and-tested-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210910090621.3073540-6-peng.fan@oss.nxp.com
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/imx_rproc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/remoteproc/imx_rproc.c
++++ b/drivers/remoteproc/imx_rproc.c
+@@ -604,7 +604,7 @@ static int imx_rproc_addr_init(struct im
+ }
+ priv->mem[b].sys_addr = res.start;
+ priv->mem[b].size = resource_size(&res);
+- if (!strcmp(node->name, "rsc_table"))
++ if (!strcmp(node->name, "rsc-table"))
+ priv->rsc_table = priv->mem[b].cpu_addr;
+ b++;
+ }
--- /dev/null
+From 3826350e6dd435e244eb6e47abad5a47c169ebc2 Mon Sep 17 00:00:00 2001
+From: Harald Freudenberger <freude@linux.ibm.com>
+Date: Thu, 14 Oct 2021 09:58:24 +0200
+Subject: s390/ap: Fix hanging ioctl caused by orphaned replies
+
+From: Harald Freudenberger <freude@linux.ibm.com>
+
+commit 3826350e6dd435e244eb6e47abad5a47c169ebc2 upstream.
+
+When a queue is switched to soft offline during heavy load and later
+switched to soft online again and now used, it may be that the caller
+is blocked forever in the ioctl call.
+
+The failure occurs because there is a pending reply after the queue(s)
+have been switched to offline. This orphaned reply is received when
+the queue is switched to online and is accidentally counted for the
+outstanding replies. So when there was a valid outstanding reply and
+this orphaned reply is received it counts as the outstanding one thus
+dropping the outstanding counter to 0. Voila, with this counter the
+receive function is not called any more and the real outstanding reply
+is never received (until another request comes in...) and the ioctl
+blocks.
+
+The fix is simple. However, instead of readjusting the counter when an
+orphaned reply is detected, I check the queue status for not empty and
+compare this to the outstanding counter. So if the queue is not empty
+then the counter must not drop to 0 but at least have a value of 1.
+
+Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/crypto/ap_queue.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/s390/crypto/ap_queue.c
++++ b/drivers/s390/crypto/ap_queue.c
+@@ -157,6 +157,8 @@ static struct ap_queue_status ap_sm_recv
+ switch (status.response_code) {
+ case AP_RESPONSE_NORMAL:
+ aq->queue_count = max_t(int, 0, aq->queue_count - 1);
++ if (!status.queue_empty && !aq->queue_count)
++ aq->queue_count++;
+ if (aq->queue_count > 0)
+ mod_timer(&aq->timeout,
+ jiffies + aq->request_timeout);
--- /dev/null
+From a4751f157c194431fae9e9c493f456df8272b871 Mon Sep 17 00:00:00 2001
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+Date: Fri, 5 Nov 2021 16:44:51 +0100
+Subject: s390/cio: check the subchannel validity for dev_busid
+
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+
+commit a4751f157c194431fae9e9c493f456df8272b871 upstream.
+
+Check the validity of subchanel before reading other fields in
+the schib.
+
+Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel")
+CC: <stable@vger.kernel.org>
+Reported-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Reviewed-by: Cornelia Huck <cohuck@redhat.com>
+Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/cio/css.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/cio/css.c
++++ b/drivers/s390/cio/css.c
+@@ -437,8 +437,8 @@ static ssize_t dev_busid_show(struct dev
+ struct subchannel *sch = to_subchannel(dev);
+ struct pmcw *pmcw = &sch->schib.pmcw;
+
+- if ((pmcw->st == SUBCHANNEL_TYPE_IO ||
+- pmcw->st == SUBCHANNEL_TYPE_MSG) && pmcw->dnv)
++ if ((pmcw->st == SUBCHANNEL_TYPE_IO && pmcw->dnv) ||
++ (pmcw->st == SUBCHANNEL_TYPE_MSG && pmcw->w))
+ return sysfs_emit(buf, "0.%x.%04x\n", sch->schid.ssid,
+ pmcw->dev);
+ else
--- /dev/null
+From ad9a14517263a16af040598c7920c09ca9670a31 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Wed, 8 Sep 2021 17:36:23 +0200
+Subject: s390/cio: make ccw_device_dma_* more robust
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit ad9a14517263a16af040598c7920c09ca9670a31 upstream.
+
+Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
+classic notifiers") we were supposed to make sure that
+virtio_ccw_release_dev() completes before the ccw device and the
+attached dma pool are torn down, but unfortunately we did not. Before
+that commit it used to be OK to delay cleaning up the memory allocated
+by virtio-ccw indefinitely (which isn't really intuitive for guys used
+to destruction happens in reverse construction order), but now we
+trigger a BUG_ON if the genpool is destroyed before all memory allocated
+from it is deallocated. Which brings down the guest. We can observe this
+problem, when unregister_virtio_device() does not give up the last
+reference to the virtio_device (e.g. because a virtio-scsi attached scsi
+disk got removed without previously unmounting its previously mounted
+partition).
+
+To make sure that the genpool is only destroyed after all the necessary
+freeing is done let us take a reference on the ccw device on each
+ccw_device_dma_zalloc() and give it up on each ccw_device_dma_free().
+
+Actually there are multiple approaches to fixing the problem at hand
+that can work. The upside of this one is that it is the safest one while
+remaining simple. We don't crash the guest even if the driver does not
+pair allocations and frees. The downside is the reference counting
+overhead, that the reference counting for ccw devices becomes more
+complex, in a sense that we need to pair the calls to the aforementioned
+functions for it to be correct, and that if we happen to leak, we leak
+more than necessary (the whole ccw device instead of just the genpool).
+
+Some alternatives to this approach are taking a reference in
+virtio_ccw_online() and giving it up in virtio_ccw_release_dev() or
+making sure virtio_ccw_release_dev() completes its work before
+virtio_ccw_remove() returns. The downside of these approaches is that
+these are less safe against programming errors.
+
+Cc: <stable@vger.kernel.org> # v5.3
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers")
+Reported-by: bfu@redhat.com
+Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Acked-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/cio/device_ops.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/cio/device_ops.c
++++ b/drivers/s390/cio/device_ops.c
+@@ -825,13 +825,23 @@ EXPORT_SYMBOL_GPL(ccw_device_get_chid);
+ */
+ void *ccw_device_dma_zalloc(struct ccw_device *cdev, size_t size)
+ {
+- return cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
++ void *addr;
++
++ if (!get_device(&cdev->dev))
++ return NULL;
++ addr = cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
++ if (IS_ERR_OR_NULL(addr))
++ put_device(&cdev->dev);
++ return addr;
+ }
+ EXPORT_SYMBOL(ccw_device_dma_zalloc);
+
+ void ccw_device_dma_free(struct ccw_device *cdev, void *cpu_addr, size_t size)
+ {
++ if (!cpu_addr)
++ return;
+ cio_gp_dma_free(cdev->private->dma_pool, cpu_addr, size);
++ put_device(&cdev->dev);
+ }
+ EXPORT_SYMBOL(ccw_device_dma_free);
+
--- /dev/null
+From 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe Mon Sep 17 00:00:00 2001
+From: Thomas Richter <tmricht@linux.ibm.com>
+Date: Wed, 3 Nov 2021 13:13:04 +0100
+Subject: s390/cpumf: cpum_cf PMU displays invalid value after hotplug remove
+
+From: Thomas Richter <tmricht@linux.ibm.com>
+
+commit 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe upstream.
+
+When a CPU is hotplugged while the perf stat -e cycles command is
+running, a wrong (very large) value is displayed immediately after the
+CPU removal:
+
+ Check the values, shouldn't be too high as in
+ time counts unit events
+ 1.001101919 29261846 cycles
+ 2.002454499 17523405 cycles
+ 3.003659292 24361161 cycles
+ 4.004816983 18446744073638406144 cycles
+ 5.005671647 <not counted> cycles
+ ...
+
+The CPU hotplug off took place after 3 seconds.
+The issue is the read of the event count value after 4 seconds when
+the CPU is not available and the read of the counter returns an
+error. This is treated as a counter value of zero. This results
+in a very large value (0 - previous_value).
+
+Fix this by detecting the hotplugged off CPU and report 0 instead
+of a very large number.
+
+Cc: stable@vger.kernel.org
+Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility")
+Reported-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
+Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
+Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kernel/perf_cpum_cf.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/s390/kernel/perf_cpum_cf.c
++++ b/arch/s390/kernel/perf_cpum_cf.c
+@@ -687,8 +687,10 @@ static void cpumf_pmu_stop(struct perf_e
+ false);
+ if (cfdiag_diffctr(cpuhw, event->hw.config_base))
+ cfdiag_push_sample(event, cpuhw);
+- } else
++ } else if (cpuhw->flags & PMU_F_RESERVED) {
++ /* Only update when PMU not hotplugged off */
+ hw_perf_event_update(event);
++ }
+ hwc->state |= PERF_HES_UPTODATE;
+ }
+ }
--- /dev/null
+From 213fca9e23b59581c573d558aa477556f00b8198 Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@linux.ibm.com>
+Date: Tue, 2 Nov 2021 10:55:30 +0100
+Subject: s390/tape: fix timer initialization in tape_std_assign()
+
+From: Sven Schnelle <svens@linux.ibm.com>
+
+commit 213fca9e23b59581c573d558aa477556f00b8198 upstream.
+
+commit 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor
+of timer_setup_on_stack()") changed the timer setup from
+init_timer_on_stack(() to timer_setup(), but missed to change the
+mod_timer() call. And while at it, use msecs_to_jiffies() instead
+of the open coded timeout calculation.
+
+Cc: stable@vger.kernel.org
+Fixes: 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()")
+Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
+Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/char/tape_std.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/s390/char/tape_std.c
++++ b/drivers/s390/char/tape_std.c
+@@ -53,7 +53,6 @@ int
+ tape_std_assign(struct tape_device *device)
+ {
+ int rc;
+- struct timer_list timeout;
+ struct tape_request *request;
+
+ request = tape_alloc_request(2, 11);
+@@ -70,7 +69,7 @@ tape_std_assign(struct tape_device *devi
+ * So we set up a timeout for this call.
+ */
+ timer_setup(&request->timer, tape_std_assign_timeout, 0);
+- mod_timer(&timeout, jiffies + 2 * HZ);
++ mod_timer(&request->timer, jiffies + msecs_to_jiffies(2000));
+
+ rc = tape_do_io_interruptible(device, request);
+
9p-net-fix-missing-error-check-in-p9_check_errors.patch
mm-filemap.c-remove-bogus-vm_bug_on.patch
memcg-prohibit-unconditional-exceeding-the-limit-of-dying-tasks.patch
+mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch
+mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch
+mm-thp-lock-filemap-when-truncating-page-cache.patch
+mm-thp-fix-incorrect-unmap-behavior-for-private-pages.patch
+mfd-dln2-add-cell-for-initializing-dln2-adc.patch
+video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch
+bcache-fix-use-after-free-problem-in-bcache_device_free.patch
+bcache-revert-bcache-use-bvec_virt.patch
+pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch
+s390-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.patch
+s390-cio-check-the-subchannel-validity-for-dev_busid.patch
+s390-tape-fix-timer-initialization-in-tape_std_assign.patch
+s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch
+s390-cio-make-ccw_device_dma_-more-robust.patch
+remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch
+remoteproc-fix-the-wrong-default-value-of-is_iomem.patch
+remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch
+remoteproc-imx_rproc-fix-rsc-table-name.patch
--- /dev/null
+From 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Tue, 21 Sep 2021 19:35:06 +0200
+Subject: video: backlight: Drop maximum brightness override for brightness zero
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Vasut <marex@denx.de>
+
+commit 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa upstream.
+
+The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
+in backlight.c") says that gpio-backlight uses brightness as power state.
+This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
+Correct initial power state handling") and other backlight drivers do not
+require this workaround. Drop the workaround.
+
+This fixes the case where e.g. pwm-backlight can perfectly well be set to
+brightness 0 on boot in DT, which without this patch leads to the display
+brightness to be max instead of off.
+
+Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c")
+Cc: <stable@vger.kernel.org> # 5.4+
+Cc: <stable@vger.kernel.org> # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling
+Signed-off-by: Marek Vasut <marex@denx.de>
+Acked-by: Noralf Trønnes <noralf@tronnes.org>
+Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/backlight/backlight.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/drivers/video/backlight/backlight.c
++++ b/drivers/video/backlight/backlight.c
+@@ -688,12 +688,6 @@ static struct backlight_device *of_find_
+ of_node_put(np);
+ if (!bd)
+ return ERR_PTR(-EPROBE_DEFER);
+- /*
+- * Note: gpio_backlight uses brightness as
+- * power state during probe
+- */
+- if (!bd->props.brightness)
+- bd->props.brightness = bd->props.max_brightness;
+ }
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
