--- /dev/null
+From 66f133ceab7456c789f70a242991ed1b27ba1c3d Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Fri, 8 Apr 2022 13:08:55 -0700
+Subject: highmem: fix checks in __kmap_local_sched_{in,out}
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit 66f133ceab7456c789f70a242991ed1b27ba1c3d upstream.
+
+When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check
+that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are
+initialized with 0 value, but the check is done with pte_none. 0 pte
+however does not necessarily mean that pte_none will return true. e.g.
+on xtensa it returns false, resulting in the following runtime warnings:
+
+ WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108
+ CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
+ Call Trace:
+ dump_stack+0xc/0x40
+ __warn+0x8f/0x174
+ warn_slowpath_fmt+0x48/0xac
+ __kmap_local_sched_out+0x51/0x108
+ __schedule+0x71a/0x9c4
+ preempt_schedule_irq+0xa0/0xe0
+ common_exception_return+0x5c/0x93
+ do_wp_page+0x30e/0x330
+ handle_mm_fault+0xa70/0xc3c
+ do_page_fault+0x1d8/0x3c4
+ common_exception+0x7f/0x7f
+
+ WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0
+ CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
+ Call Trace:
+ dump_stack+0xc/0x40
+ __warn+0x8f/0x174
+ warn_slowpath_fmt+0x48/0xac
+ __kmap_local_sched_in+0x50/0xe0
+ finish_task_switch$isra$0+0x1ce/0x2f8
+ __schedule+0x86e/0x9c4
+ preempt_schedule_irq+0xa0/0xe0
+ common_exception_return+0x5c/0x93
+ do_wp_page+0x30e/0x330
+ handle_mm_fault+0xa70/0xc3c
+ do_page_fault+0x1d8/0x3c4
+ common_exception+0x7f/0x7f
+
+Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.
+
+Link: https://lkml.kernel.org/r/20220403235159.3498065-1-jcmvbkbc@gmail.com
+Fixes: 5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct")
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
+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/highmem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/highmem.c
++++ b/mm/highmem.c
+@@ -624,7 +624,7 @@ void __kmap_local_sched_out(void)
+
+ /* With debug all even slots are unmapped and act as guard */
+ if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) {
+- WARN_ON_ONCE(!pte_none(pteval));
++ WARN_ON_ONCE(pte_val(pteval) != 0);
+ continue;
+ }
+ if (WARN_ON_ONCE(pte_none(pteval)))
+@@ -661,7 +661,7 @@ void __kmap_local_sched_in(void)
+
+ /* With debug all even slots are unmapped and act as guard */
+ if (IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL) && !(i & 0x01)) {
+- WARN_ON_ONCE(!pte_none(pteval));
++ WARN_ON_ONCE(pte_val(pteval) != 0);
+ continue;
+ }
+ if (WARN_ON_ONCE(pte_none(pteval)))
--- /dev/null
+From a3e4bc23d5470b2beb7cc42a86b6a3e75b704c15 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 29 Mar 2022 10:59:20 -0600
+Subject: io_uring: defer splice/tee file validity check until command issue
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit a3e4bc23d5470b2beb7cc42a86b6a3e75b704c15 upstream.
+
+In preparation for not using the file at prep time, defer checking if this
+file refers to a valid io_uring instance until issue time.
+
+This also means we can get rid of the cleanup flag for splice and tee.
+
+Cc: stable@vger.kernel.org # v5.15+
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/io_uring.c | 49 +++++++++++++++++++++----------------------------
+ 1 file changed, 21 insertions(+), 28 deletions(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -619,10 +619,10 @@ struct io_epoll {
+
+ struct io_splice {
+ struct file *file_out;
+- struct file *file_in;
+ loff_t off_out;
+ loff_t off_in;
+ u64 len;
++ int splice_fd_in;
+ unsigned int flags;
+ };
+
+@@ -1524,14 +1524,6 @@ static void io_prep_async_work(struct io
+ if (def->unbound_nonreg_file)
+ req->work.flags |= IO_WQ_WORK_UNBOUND;
+ }
+-
+- switch (req->opcode) {
+- case IORING_OP_SPLICE:
+- case IORING_OP_TEE:
+- if (!S_ISREG(file_inode(req->splice.file_in)->i_mode))
+- req->work.flags |= IO_WQ_WORK_UNBOUND;
+- break;
+- }
+ }
+
+ static void io_prep_async_link(struct io_kiocb *req)
+@@ -4054,18 +4046,11 @@ static int __io_splice_prep(struct io_ki
+ if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
+ return -EINVAL;
+
+- sp->file_in = NULL;
+ sp->len = READ_ONCE(sqe->len);
+ sp->flags = READ_ONCE(sqe->splice_flags);
+-
+ if (unlikely(sp->flags & ~valid_flags))
+ return -EINVAL;
+-
+- sp->file_in = io_file_get(req->ctx, req, READ_ONCE(sqe->splice_fd_in),
+- (sp->flags & SPLICE_F_FD_IN_FIXED));
+- if (!sp->file_in)
+- return -EBADF;
+- req->flags |= REQ_F_NEED_CLEANUP;
++ sp->splice_fd_in = READ_ONCE(sqe->splice_fd_in);
+ return 0;
+ }
+
+@@ -4080,20 +4065,27 @@ static int io_tee_prep(struct io_kiocb *
+ static int io_tee(struct io_kiocb *req, unsigned int issue_flags)
+ {
+ struct io_splice *sp = &req->splice;
+- struct file *in = sp->file_in;
+ struct file *out = sp->file_out;
+ unsigned int flags = sp->flags & ~SPLICE_F_FD_IN_FIXED;
++ struct file *in;
+ long ret = 0;
+
+ if (issue_flags & IO_URING_F_NONBLOCK)
+ return -EAGAIN;
++
++ in = io_file_get(req->ctx, req, sp->splice_fd_in,
++ (sp->flags & SPLICE_F_FD_IN_FIXED));
++ if (!in) {
++ ret = -EBADF;
++ goto done;
++ }
++
+ if (sp->len)
+ ret = do_tee(in, out, sp->len, flags);
+
+ if (!(sp->flags & SPLICE_F_FD_IN_FIXED))
+ io_put_file(in);
+- req->flags &= ~REQ_F_NEED_CLEANUP;
+-
++done:
+ if (ret != sp->len)
+ req_set_fail(req);
+ io_req_complete(req, ret);
+@@ -4112,15 +4104,22 @@ static int io_splice_prep(struct io_kioc
+ static int io_splice(struct io_kiocb *req, unsigned int issue_flags)
+ {
+ struct io_splice *sp = &req->splice;
+- struct file *in = sp->file_in;
+ struct file *out = sp->file_out;
+ unsigned int flags = sp->flags & ~SPLICE_F_FD_IN_FIXED;
+ loff_t *poff_in, *poff_out;
++ struct file *in;
+ long ret = 0;
+
+ if (issue_flags & IO_URING_F_NONBLOCK)
+ return -EAGAIN;
+
++ in = io_file_get(req->ctx, req, sp->splice_fd_in,
++ (sp->flags & SPLICE_F_FD_IN_FIXED));
++ if (!in) {
++ ret = -EBADF;
++ goto done;
++ }
++
+ poff_in = (sp->off_in == -1) ? NULL : &sp->off_in;
+ poff_out = (sp->off_out == -1) ? NULL : &sp->off_out;
+
+@@ -4129,8 +4128,7 @@ static int io_splice(struct io_kiocb *re
+
+ if (!(sp->flags & SPLICE_F_FD_IN_FIXED))
+ io_put_file(in);
+- req->flags &= ~REQ_F_NEED_CLEANUP;
+-
++done:
+ if (ret != sp->len)
+ req_set_fail(req);
+ io_req_complete(req, ret);
+@@ -6630,11 +6628,6 @@ static void io_clean_op(struct io_kiocb
+ kfree(io->free_iov);
+ break;
+ }
+- case IORING_OP_SPLICE:
+- case IORING_OP_TEE:
+- if (!(req->splice.flags & SPLICE_F_FD_IN_FIXED))
+- io_put_file(req->splice.file_in);
+- break;
+ case IORING_OP_OPENAT:
+ case IORING_OP_OPENAT2:
+ if (req->open.filename)
--- /dev/null
+From ec858afda857e361182ceafc3d2ba2b164b8e889 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 30 Mar 2022 11:06:02 -0600
+Subject: io_uring: don't check req->file in io_fsync_prep()
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit ec858afda857e361182ceafc3d2ba2b164b8e889 upstream.
+
+This is a leftover from the really old days where we weren't able to
+track and error early if we need a file and it wasn't assigned. Kill
+the check.
+
+Cc: stable@vger.kernel.org # v5.15+
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/io_uring.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -4155,9 +4155,6 @@ static int io_fsync_prep(struct io_kiocb
+ {
+ struct io_ring_ctx *ctx = req->ctx;
+
+- if (!req->file)
+- return -EBADF;
+-
+ if (unlikely(ctx->flags & IORING_SETUP_IOPOLL))
+ return -EINVAL;
+ if (unlikely(sqe->addr || sqe->ioprio || sqe->buf_index ||
--- /dev/null
+From eafc0a02391b7b36617b36c97c4b5d6832cf5e24 Mon Sep 17 00:00:00 2001
+From: Guo Xuenan <guoxuenan@huawei.com>
+Date: Fri, 8 Apr 2022 13:08:58 -0700
+Subject: lz4: fix LZ4_decompress_safe_partial read out of bound
+
+From: Guo Xuenan <guoxuenan@huawei.com>
+
+commit eafc0a02391b7b36617b36c97c4b5d6832cf5e24 upstream.
+
+When partialDecoding, it is EOF if we've either filled the output buffer
+or can't proceed with reading an offset for following match.
+
+In some extreme corner cases when compressed data is suitably corrupted,
+UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial
+may lead to read out of bound problem during decoding. lz4 upstream has
+fixed it [2] and this issue has been disscussed here [3] before.
+
+current decompression routine was ported from lz4 v1.8.3, bumping
+lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd
+better fix it first.
+
+[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/
+[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
+[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
+
+Link: https://lkml.kernel.org/r/20211111105048.2006070-1-guoxuenan@huawei.com
+Reported-by: syzbot+63d688f1d899c588fb71@syzkaller.appspotmail.com
+Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
+Reviewed-by: Nick Terrell <terrelln@fb.com>
+Acked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
+Cc: Yann Collet <cyan@fb.com>
+Cc: Chengyang Fan <cy.fan@huawei.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>
+---
+ lib/lz4/lz4_decompress.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/lib/lz4/lz4_decompress.c
++++ b/lib/lz4/lz4_decompress.c
+@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_g
+ ip += length;
+ op += length;
+
+- /* Necessarily EOF, due to parsing restrictions */
+- if (!partialDecoding || (cpy == oend))
++ /* Necessarily EOF when !partialDecoding.
++ * When partialDecoding, it is EOF if we've either
++ * filled the output buffer or
++ * can't proceed with reading an offset for following match.
++ */
++ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2)))
+ break;
+ } else {
+ /* may overwrite up to WILDCOPYLENGTH beyond cpy */
--- /dev/null
+From 4ad099559b00ac01c3726e5c95dc3108ef47d03e Mon Sep 17 00:00:00 2001
+From: Miaohe Lin <linmiaohe@huawei.com>
+Date: Fri, 8 Apr 2022 13:09:07 -0700
+Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace
+
+From: Miaohe Lin <linmiaohe@huawei.com>
+
+commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream.
+
+If mpol_new is allocated but not used in restart loop, mpol_new will be
+freed via mpol_put before returning to the caller. But refcnt is not
+initialized yet, so mpol_put could not do the right things and might
+leak the unused mpol_new. This would happen if mempolicy was updated on
+the shared shmem file while the sp->lock has been dropped during the
+memory allocation.
+
+This issue could be triggered easily with the below code snippet if
+there are many processes doing the below work at the same time:
+
+ shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);
+ shm = shmat(shmid, 0, 0);
+ loop many times {
+ mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);
+ mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,
+ maxnode, 0);
+ }
+
+Link: https://lkml.kernel.org/r/20220329111416.27954-1-linmiaohe@huawei.com
+Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock")
+Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: <stable@vger.kernel.org> [3.8]
+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/mempolicy.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -2653,6 +2653,7 @@ alloc_new:
+ mpol_new = kmem_cache_alloc(policy_cache, GFP_KERNEL);
+ if (!mpol_new)
+ goto err_out;
++ atomic_set(&mpol_new->refcnt, 1);
+ goto restart;
+ }
+
--- /dev/null
+From 5d435933376962b107bd76970912e7e80247dcc7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20L=C3=B6hle?= <CLoehle@hyperstone.com>
+Date: Thu, 24 Mar 2022 14:18:41 +0000
+Subject: mmc: block: Check for errors after write on SPI
+
+From: Christian Löhle <CLoehle@hyperstone.com>
+
+commit 5d435933376962b107bd76970912e7e80247dcc7 upstream.
+
+Introduce a SEND_STATUS check for writes through SPI to not mark
+an unsuccessful write as successful.
+
+Since SPI SD/MMC does not have states, after a write, the card will
+just hold the line LOW until it is ready again. The driver marks the
+write therefore as completed as soon as it reads something other than
+all zeroes.
+The driver does not distinguish from a card no longer signalling busy
+and it being disconnected (and the line being pulled-up by the host).
+This lead to writes being marked as successful when disconnecting
+a busy card.
+Now the card is ensured to be still connected by an additional CMD13,
+just like non-SPI is ensured to go back to TRAN state.
+
+While at it and since we already poll for the post-write status anyway,
+we might as well check for SPIs error bits (any of them).
+
+The disconnecting card problem is reproducable for me after continuous
+write activity and randomly disconnecting, around every 20-50 tries
+on SPI DS for some card.
+
+Fixes: 7213d175e3b6f ("MMC/SD card driver learns SPI")
+Cc: stable@vger.kernel.org
+Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/76f6f5d2b35543bab3dfe438f268609c@hyperstone.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/block.c | 34 +++++++++++++++++++++++++++++++++-
+ 1 file changed, 33 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -1880,6 +1880,31 @@ static inline bool mmc_blk_rq_error(stru
+ brq->data.error || brq->cmd.resp[0] & CMD_ERRORS;
+ }
+
++static int mmc_spi_err_check(struct mmc_card *card)
++{
++ u32 status = 0;
++ int err;
++
++ /*
++ * SPI does not have a TRAN state we have to wait on, instead the
++ * card is ready again when it no longer holds the line LOW.
++ * We still have to ensure two things here before we know the write
++ * was successful:
++ * 1. The card has not disconnected during busy and we actually read our
++ * own pull-up, thinking it was still connected, so ensure it
++ * still responds.
++ * 2. Check for any error bits, in particular R1_SPI_IDLE to catch a
++ * just reconnected card after being disconnected during busy.
++ */
++ err = __mmc_send_status(card, &status, 0);
++ if (err)
++ return err;
++ /* All R1 and R2 bits of SPI are errors in our case */
++ if (status)
++ return -EIO;
++ return 0;
++}
++
+ static int mmc_blk_busy_cb(void *cb_data, bool *busy)
+ {
+ struct mmc_blk_busy_data *data = cb_data;
+@@ -1903,9 +1928,16 @@ static int mmc_blk_card_busy(struct mmc_
+ struct mmc_blk_busy_data cb_data;
+ int err;
+
+- if (mmc_host_is_spi(card->host) || rq_data_dir(req) == READ)
++ if (rq_data_dir(req) == READ)
+ return 0;
+
++ if (mmc_host_is_spi(card->host)) {
++ err = mmc_spi_err_check(card);
++ if (err)
++ mqrq->brq.data.bytes_xfered = 0;
++ return err;
++ }
++
+ cb_data.card = card;
+ cb_data.status = 0;
+ err = __mmc_poll_for_busy(card, MMC_BLK_TIMEOUT_MS, &mmc_blk_busy_cb,
--- /dev/null
+From 08ebf903af57cda6d773f3dd1671b64f73b432b8 Mon Sep 17 00:00:00 2001
+From: Michael Wu <michael@allwinnertech.com>
+Date: Thu, 31 Mar 2022 15:32:23 +0800
+Subject: mmc: core: Fixup support for writeback-cache for eMMC and SD
+
+From: Michael Wu <michael@allwinnertech.com>
+
+commit 08ebf903af57cda6d773f3dd1671b64f73b432b8 upstream.
+
+During the card initialization process, the mmc core checks whether the
+eMMC/SD card supports an internal writeback-cache and then enables it
+inside the card.
+
+Unfortunately, this isn't according to what the mmc core reports to the
+upper block layer. Instead, the writeback-cache support with REQ_FLUSH and
+REQ_FUA, are being enabled depending on whether the host supports the CMD23
+(MMC_CAP_CMD23) and whether an eMMC supports the reliable-write command.
+
+This is wrong and it may also sound awkward. In fact, it's a remnant
+from when both eMMC/SD cards didn't have dedicated commands/support to
+control the internal writeback-cache. In other words, it was the best we
+could do at that point in time.
+
+To fix the problem, but also without breaking backwards compatibility,
+let's align the REQ_FLUSH support with whether the writeback-cache became
+successfully enabled - for both eMMC and SD cards.
+
+Cc: stable@kernel.org
+Fixes: 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device")
+Fixes: 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards")
+Depends-on: 97fce126e279 ("mmc: block: Issue a cache flush only when it's enabled")
+Reviewed-by: Avri Altman <Avri.Altman@wdc.com>
+Signed-off-by: Michael Wu <michael@allwinnertech.com>
+Link: https://lore.kernel.org/r/20220331073223.106415-1-michael@allwinnertech.com
+[Ulf: Re-wrote the commit message]
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/block.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -2376,6 +2376,8 @@ static struct mmc_blk_data *mmc_blk_allo
+ struct mmc_blk_data *md;
+ int devidx, ret;
+ char cap_str[10];
++ bool cache_enabled = false;
++ bool fua_enabled = false;
+
+ devidx = ida_simple_get(&mmc_blk_ida, 0, max_devices, GFP_KERNEL);
+ if (devidx < 0) {
+@@ -2457,13 +2459,17 @@ static struct mmc_blk_data *mmc_blk_allo
+ md->flags |= MMC_BLK_CMD23;
+ }
+
+- if (mmc_card_mmc(card) &&
+- md->flags & MMC_BLK_CMD23 &&
++ if (md->flags & MMC_BLK_CMD23 &&
+ ((card->ext_csd.rel_param & EXT_CSD_WR_REL_PARAM_EN) ||
+ card->ext_csd.rel_sectors)) {
+ md->flags |= MMC_BLK_REL_WR;
+- blk_queue_write_cache(md->queue.queue, true, true);
++ fua_enabled = true;
++ cache_enabled = true;
+ }
++ if (mmc_cache_enabled(card->host))
++ cache_enabled = true;
++
++ blk_queue_write_cache(md->queue.queue, cache_enabled, fua_enabled);
+
+ string_get_size((u64)size, 512, STRING_UNITS_2,
+ cap_str, sizeof(cap_str));
--- /dev/null
+From 0d319dd5a27183b75d984e3dc495248e59f99334 Mon Sep 17 00:00:00 2001
+From: Yann Gautier <yann.gautier@foss.st.com>
+Date: Thu, 17 Mar 2022 12:19:43 +0100
+Subject: mmc: mmci: stm32: correctly check all elements of sg list
+
+From: Yann Gautier <yann.gautier@foss.st.com>
+
+commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream.
+
+Use sg and not data->sg when checking sg list elements. Else only the
+first element alignment is checked.
+The last element should be checked the same way, for_each_sg already set
+sg to sg_next(sg).
+
+Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
+Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/mmci_stm32_sdmmc.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
++++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
+@@ -62,8 +62,8 @@ static int sdmmc_idma_validate_data(stru
+ * excepted the last element which has no constraint on idmasize
+ */
+ for_each_sg(data->sg, sg, data->sg_len - 1, i) {
+- if (!IS_ALIGNED(data->sg->offset, sizeof(u32)) ||
+- !IS_ALIGNED(data->sg->length, SDMMC_IDMA_BURST)) {
++ if (!IS_ALIGNED(sg->offset, sizeof(u32)) ||
++ !IS_ALIGNED(sg->length, SDMMC_IDMA_BURST)) {
+ dev_err(mmc_dev(host->mmc),
+ "unaligned scatterlist: ofst:%x length:%d\n",
+ data->sg->offset, data->sg->length);
+@@ -71,7 +71,7 @@ static int sdmmc_idma_validate_data(stru
+ }
+ }
+
+- if (!IS_ALIGNED(data->sg->offset, sizeof(u32))) {
++ if (!IS_ALIGNED(sg->offset, sizeof(u32))) {
+ dev_err(mmc_dev(host->mmc),
+ "unaligned last scatterlist: ofst:%x length:%d\n",
+ data->sg->offset, data->sg->length);
--- /dev/null
+From 03e59b1e2f56245163b14c69e0a830c24b1a3a47 Mon Sep 17 00:00:00 2001
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Date: Mon, 4 Apr 2022 13:49:02 +0200
+Subject: mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete
+
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream.
+
+When HS400 tuning is complete and HS400 is going to be activated, we
+have to keep the current number of TAPs and should not overwrite them
+with a hardcoded value. This was probably a copy&paste mistake when
+upporting HS400 support from the BSP.
+
+Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
+Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/renesas_sdhi_core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/renesas_sdhi_core.c
++++ b/drivers/mmc/host/renesas_sdhi_core.c
+@@ -382,10 +382,10 @@ static void renesas_sdhi_hs400_complete(
+ SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) |
+ sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2));
+
+- /* Set the sampling clock selection range of HS400 mode */
+ sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
+ SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN |
+- 0x4 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT);
++ sd_scc_read32(host, priv,
++ SH_MOBILE_SDHI_SCC_DTCNTL));
+
+ /* Avoid bad TAP */
+ if (bad_taps & BIT(priv->tap_set)) {
--- /dev/null
+From 01e67e04c28170c47700c2c226d732bbfedb1ad0 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Fri, 8 Apr 2022 13:09:04 -0700
+Subject: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream.
+
+If an mremap() syscall with old_size=0 ends up in move_page_tables(), it
+will call invalidate_range_start()/invalidate_range_end() unnecessarily,
+i.e. with an empty range.
+
+This causes a WARN in KVM's mmu_notifier. In the past, empty ranges
+have been diagnosed to be off-by-one bugs, hence the WARNing. Given the
+low (so far) number of unique reports, the benefits of detecting more
+buggy callers seem to outweigh the cost of having to fix cases such as
+this one, where userspace is doing something silly. In this particular
+case, an early return from move_page_tables() is enough to fix the
+issue.
+
+Link: https://lkml.kernel.org/r/20220329173155.172439-1-pbonzini@redhat.com
+Reported-by: syzbot+6bde52d89cfdf9f61425@syzkaller.appspotmail.com
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Sean Christopherson <seanjc@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>
+---
+ mm/mremap.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/mremap.c
++++ b/mm/mremap.c
+@@ -486,6 +486,9 @@ unsigned long move_page_tables(struct vm
+ pmd_t *old_pmd, *new_pmd;
+ pud_t *old_pud, *new_pud;
+
++ if (!len)
++ return 0;
++
+ old_end = old_addr + len;
+ flush_cache_range(vma, old_addr, old_end);
+
--- /dev/null
+From 7e2646ed47542123168d43916b84b954532e5386 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+Date: Fri, 18 Mar 2022 15:14:41 +0100
+Subject: Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pali Rohár <pali@kernel.org>
+
+commit 7e2646ed47542123168d43916b84b954532e5386 upstream.
+
+This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.
+
+Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
+contains proper fix for the issue described in commit bb32e1987bc5 ("mmc:
+sdhci-xenon: fix annoying 1.8V regulator warning").
+
+Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable")
+Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization")
+Signed-off-by: Pali Rohár <pali@kernel.org>
+Reviewed-by: Marek Behún <kabel@kernel.org>
+Reviewed-by: Marcin Wojtas <mw@semihalf.com>
+Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-xenon.c | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-xenon.c
++++ b/drivers/mmc/host/sdhci-xenon.c
+@@ -241,16 +241,6 @@ static void xenon_voltage_switch(struct
+ {
+ /* Wait for 5ms after set 1.8V signal enable bit */
+ usleep_range(5000, 5500);
+-
+- /*
+- * For some reason the controller's Host Control2 register reports
+- * the bit representing 1.8V signaling as 0 when read after it was
+- * written as 1. Subsequent read reports 1.
+- *
+- * Since this may cause some issues, do an empty read of the Host
+- * Control2 register here to circumvent this.
+- */
+- sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ }
+
+ static unsigned int xenon_get_max_clock(struct sdhci_host *host)
--- /dev/null
+From 87d663d40801dffc99a5ad3b0188ad3e2b4d1557 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Date: Tue, 22 Mar 2022 14:57:02 +0900
+Subject: scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()
+
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+commit 87d663d40801dffc99a5ad3b0188ad3e2b4d1557 upstream.
+
+The function mpt3sas_transport_port_remove() called in
+_scsih_expander_node_remove() frees the port field of the sas_expander
+structure, leading to the following use-after-free splat from KASAN when
+the ioc_info() call following that function is executed (e.g. when doing
+rmmod of the driver module):
+
+[ 3479.371167] ==================================================================
+[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
+[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531
+[ 3479.393524]
+[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436
+[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021
+[ 3479.409263] Call Trace:
+[ 3479.411743] <TASK>
+[ 3479.413875] dump_stack_lvl+0x45/0x59
+[ 3479.417582] print_address_description.constprop.0+0x1f/0x120
+[ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
+[ 3479.429469] kasan_report.cold+0x83/0xdf
+[ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
+[ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas]
+[ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40
+[ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas]
+[ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]
+[ 3479.465529] ? down_write+0xde/0x150
+[ 3479.470746] ? up_write+0x14d/0x460
+[ 3479.475840] ? kernfs_find_ns+0x137/0x310
+[ 3479.481438] pci_device_remove+0x65/0x110
+[ 3479.487013] __device_release_driver+0x316/0x680
+[ 3479.493180] driver_detach+0x1ec/0x2d0
+[ 3479.498499] bus_remove_driver+0xe7/0x2d0
+[ 3479.504081] pci_unregister_driver+0x26/0x250
+[ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas]
+[ 3479.516144] __x64_sys_delete_module+0x2fd/0x510
+[ 3479.522315] ? free_module+0xaa0/0xaa0
+[ 3479.527593] ? __cond_resched+0x1c/0x90
+[ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
+[ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70
+[ 3479.546161] ? trace_hardirqs_on+0x1c/0x110
+[ 3479.551828] do_syscall_64+0x35/0x80
+[ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae
+[ 3479.563402] RIP: 0033:0x7f1fc482483b
+...
+[ 3479.943087] ==================================================================
+
+Fix this by introducing the local variable port_id to store the port ID
+value before executing mpt3sas_transport_port_remove(). This local variable
+is then used in the call to ioc_info() instead of dereferencing the freed
+port structure.
+
+Link: https://lore.kernel.org/r/20220322055702.95276-1-damien.lemoal@opensource.wdc.com
+Fixes: 7d310f241001 ("scsi: mpt3sas: Get device objects using sas_address & portID")
+Cc: stable@vger.kernel.org
+Acked-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
++++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+@@ -11035,6 +11035,7 @@ _scsih_expander_node_remove(struct MPT3S
+ {
+ struct _sas_port *mpt3sas_port, *next;
+ unsigned long flags;
++ int port_id;
+
+ /* remove sibling ports attached to this expander */
+ list_for_each_entry_safe(mpt3sas_port, next,
+@@ -11055,6 +11056,8 @@ _scsih_expander_node_remove(struct MPT3S
+ mpt3sas_port->hba_port);
+ }
+
++ port_id = sas_expander->port->port_id;
++
+ mpt3sas_transport_port_remove(ioc, sas_expander->sas_address,
+ sas_expander->sas_address_parent, sas_expander->port);
+
+@@ -11062,7 +11065,7 @@ _scsih_expander_node_remove(struct MPT3S
+ "expander_remove: handle(0x%04x), sas_addr(0x%016llx), port:%d\n",
+ sas_expander->handle, (unsigned long long)
+ sas_expander->sas_address,
+- sas_expander->port->port_id);
++ port_id);
+
+ spin_lock_irqsave(&ioc->sas_node_lock, flags);
+ list_del(&sas_expander->list);
--- /dev/null
+From 4049f7acef3eb37c1ea0df45f3ffc29404f4e708 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 4 Apr 2022 08:50:38 +0300
+Subject: scsi: ufs: ufs-pci: Add support for Intel MTL
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 4049f7acef3eb37c1ea0df45f3ffc29404f4e708 upstream.
+
+Add PCI ID and callbacks to support Intel Meteor Lake (MTL).
+
+Link: https://lore.kernel.org/r/20220404055038.2208051-1-adrian.hunter@intel.com
+Cc: stable@vger.kernel.org # v5.15+
+Reviewed-by: Avri Altman <avri.altman@wdc.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/ufs/ufshcd-pci.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/drivers/scsi/ufs/ufshcd-pci.c
++++ b/drivers/scsi/ufs/ufshcd-pci.c
+@@ -428,6 +428,12 @@ static int ufs_intel_adl_init(struct ufs
+ return ufs_intel_common_init(hba);
+ }
+
++static int ufs_intel_mtl_init(struct ufs_hba *hba)
++{
++ hba->caps |= UFSHCD_CAP_CRYPTO | UFSHCD_CAP_WB_EN;
++ return ufs_intel_common_init(hba);
++}
++
+ static struct ufs_hba_variant_ops ufs_intel_cnl_hba_vops = {
+ .name = "intel-pci",
+ .init = ufs_intel_common_init,
+@@ -465,6 +471,16 @@ static struct ufs_hba_variant_ops ufs_in
+ .device_reset = ufs_intel_device_reset,
+ };
+
++static struct ufs_hba_variant_ops ufs_intel_mtl_hba_vops = {
++ .name = "intel-pci",
++ .init = ufs_intel_mtl_init,
++ .exit = ufs_intel_common_exit,
++ .hce_enable_notify = ufs_intel_hce_enable_notify,
++ .link_startup_notify = ufs_intel_link_startup_notify,
++ .resume = ufs_intel_resume,
++ .device_reset = ufs_intel_device_reset,
++};
++
+ #ifdef CONFIG_PM_SLEEP
+ static int ufshcd_pci_restore(struct device *dev)
+ {
+@@ -579,6 +595,7 @@ static const struct pci_device_id ufshcd
+ { PCI_VDEVICE(INTEL, 0x98FA), (kernel_ulong_t)&ufs_intel_lkf_hba_vops },
+ { PCI_VDEVICE(INTEL, 0x51FF), (kernel_ulong_t)&ufs_intel_adl_hba_vops },
+ { PCI_VDEVICE(INTEL, 0x54FF), (kernel_ulong_t)&ufs_intel_adl_hba_vops },
++ { PCI_VDEVICE(INTEL, 0x7E47), (kernel_ulong_t)&ufs_intel_mtl_hba_vops },
+ { } /* terminate list */
+ };
+
perf-tools-fix-perf-s-libperf_print-callback.patch
perf-session-remap-buf-if-there-is-no-space-for-even.patch
arm64-add-part-number-for-arm-cortex-a78ae.patch
+scsi-mpt3sas-fix-use-after-free-in-_scsih_expander_node_remove.patch
+scsi-ufs-ufs-pci-add-support-for-intel-mtl.patch
+revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch
+mmc-block-check-for-errors-after-write-on-spi.patch
+mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch
+mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch
+mmc-core-fixup-support-for-writeback-cache-for-emmc-and-sd.patch
+lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch
+highmem-fix-checks-in-__kmap_local_sched_-in-out.patch
+mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch
+mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch
+io_uring-don-t-check-req-file-in-io_fsync_prep.patch
+io_uring-defer-splice-tee-file-validity-check-until-command-issue.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
