--- /dev/null
+From 9cea62b2cbabff8ed46f2df17778b624ad9dd25a Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 4 Jan 2023 08:52:06 -0700
+Subject: block: don't allow splitting of a REQ_NOWAIT bio
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 9cea62b2cbabff8ed46f2df17778b624ad9dd25a upstream.
+
+If we split a bio marked with REQ_NOWAIT, then we can trigger spurious
+EAGAIN if constituent parts of that split bio end up failing request
+allocations. Parts will complete just fine, but just a single failure
+in one of the chained bios will yield an EAGAIN final result for the
+parent bio.
+
+Return EAGAIN early if we end up needing to split such a bio, which
+allows for saner recovery handling.
+
+Cc: stable@vger.kernel.org # 5.15+
+Link: https://github.com/axboe/liburing/issues/766
+Reported-by: Michael Kelley <mikelley@microsoft.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-merge.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/block/blk-merge.c
++++ b/block/blk-merge.c
+@@ -279,6 +279,16 @@ static struct bio *blk_bio_segment_split
+ *segs = nsegs;
+ return NULL;
+ split:
++ /*
++ * We can't sanely support splitting for a REQ_NOWAIT bio. End it
++ * with EAGAIN if splitting is required and return an error pointer.
++ */
++ if (bio->bi_opf & REQ_NOWAIT) {
++ bio->bi_status = BLK_STS_AGAIN;
++ bio_endio(bio);
++ return ERR_PTR(-EAGAIN);
++ }
++
+ *segs = nsegs;
+
+ /*
--- /dev/null
+From f685dd7a8025f2554f73748cfdb8143a21fb92c7 Mon Sep 17 00:00:00 2001
+From: Paul Menzel <pmenzel@molgen.mpg.de>
+Date: Mon, 2 Jan 2023 14:57:30 +0100
+Subject: fbdev: matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Paul Menzel <pmenzel@molgen.mpg.de>
+
+commit f685dd7a8025f2554f73748cfdb8143a21fb92c7 upstream.
+
+Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to
+the same as vbG200 to avoid black screen") accidently decreases the
+maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB
+by missing one zero. This caused the driver initialization to fail with
+the messages below, as the minimum required VRAM size is 2 MB:
+
+ [ 9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected
+ [ 9.444502] matroxfb: cannot determine memory size
+ [ 9.449316] matroxfb: probe of 0000:0a:03.0 failed with error -1
+
+So, add the missing 0 to make it the intended 16 MB. Successfully tested on
+the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is
+gone.
+
+While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned
+properly. The value could probably also be increased from 8 MB to 16 MB, as
+the G200 uses the same values, but I have not checked any datasheet.
+
+Note, matroxfb is obsolete and superseded by the maintained DRM driver
+mga200, which is used by default on most systems where both drivers are
+available. Therefore, on most systems it was only a cosmetic issue.
+
+Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen")
+Link: https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52ac5@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775
+Cc: it+linux-fbdev@molgen.mpg.de
+Cc: Z. Liu <liuzx@knownsec.com>
+Cc: Rich Felker <dalias@libc.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/matrox/matroxfb_base.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/video/fbdev/matrox/matroxfb_base.c
++++ b/drivers/video/fbdev/matrox/matroxfb_base.c
+@@ -1377,8 +1377,8 @@ static struct video_board vbG200 = {
+ .lowlevel = &matrox_G100
+ };
+ static struct video_board vbG200eW = {
+- .maxvram = 0x100000,
+- .maxdisplayable = 0x800000,
++ .maxvram = 0x1000000,
++ .maxdisplayable = 0x0800000,
+ .accelID = FB_ACCEL_MATROX_MGAG200,
+ .lowlevel = &matrox_G100
+ };
--- /dev/null
+From 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 Mon Sep 17 00:00:00 2001
+From: Pavel Begunkov <asml.silence@gmail.com>
+Date: Thu, 5 Jan 2023 10:49:15 +0000
+Subject: io_uring: fix CQ waiting timeout handling
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+commit 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 upstream.
+
+Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
+particular we rearm it anew every time we get into
+io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
+CQEs and getting a task_work in the middle may double the timeout value,
+or even worse in some cases task may wait indefinitely.
+
+Cc: stable@vger.kernel.org
+Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.1672915663.git.asml.silence@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io_uring.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/io_uring/io_uring.c
++++ b/io_uring/io_uring.c
+@@ -7598,7 +7598,7 @@ static int io_run_task_work_sig(void)
+ /* when returns >0, the caller should retry */
+ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
+ struct io_wait_queue *iowq,
+- ktime_t timeout)
++ ktime_t *timeout)
+ {
+ int ret;
+
+@@ -7610,7 +7610,7 @@ static inline int io_cqring_wait_schedul
+ if (test_bit(0, &ctx->check_cq_overflow))
+ return 1;
+
+- if (!schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS))
++ if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
+ return -ETIME;
+ return 1;
+ }
+@@ -7673,7 +7673,7 @@ static int io_cqring_wait(struct io_ring
+ }
+ prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
+ TASK_INTERRUPTIBLE);
+- ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
++ ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
+ finish_wait(&ctx->cq_wait, &iowq.wq);
+ cond_resched();
+ } while (ret > 0);
--- /dev/null
+From af82425c6a2d2f347c79b63ce74fca6dc6be157f Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Mon, 2 Jan 2023 16:49:46 -0700
+Subject: io_uring/io-wq: free worker if task_work creation is canceled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit af82425c6a2d2f347c79b63ce74fca6dc6be157f upstream.
+
+If we cancel the task_work, the worker will never come into existance.
+As this is the last reference to it, ensure that we get it freed
+appropriately.
+
+Cc: stable@vger.kernel.org
+Reported-by: 진호 <wnwlsgh98@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io-wq.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/io_uring/io-wq.c
++++ b/io_uring/io-wq.c
+@@ -1217,6 +1217,7 @@ static void io_wq_cancel_tw_create(struc
+
+ worker = container_of(cb, struct io_worker, create_work);
+ io_worker_cancel_cb(worker);
++ kfree(worker);
+ }
+ }
+
--- /dev/null
+From cad853374d85fe678d721512cecfabd7636e51f3 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Tue, 13 Dec 2022 13:08:26 -0500
+Subject: nfsd: fix handling of readdir in v4root vs. mount upcall timeout
+
+From: Jeff Layton <jlayton@kernel.org>
+
+commit cad853374d85fe678d721512cecfabd7636e51f3 upstream.
+
+If v4 READDIR operation hits a mountpoint and gets back an error,
+then it will include that entry in the reply and set RDATTR_ERROR for it
+to the error.
+
+That's fine for "normal" exported filesystems, but on the v4root, we
+need to be more careful to only expose the existence of dentries that
+lead to exports.
+
+If the mountd upcall times out while checking to see whether a
+mountpoint on the v4root is exported, then we have no recourse other
+than to fail the whole operation.
+
+Cc: Steve Dickson <steved@redhat.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=216777
+Reported-by: JianHong Yin <yin-jianhong@163.com>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4xdr.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/nfsd/nfs4xdr.c
++++ b/fs/nfsd/nfs4xdr.c
+@@ -3514,6 +3514,17 @@ nfsd4_encode_dirent(void *ccdv, const ch
+ case nfserr_noent:
+ xdr_truncate_encode(xdr, start_offset);
+ goto skip_entry;
++ case nfserr_jukebox:
++ /*
++ * The pseudoroot should only display dentries that lead to
++ * exports. If we get EJUKEBOX here, then we can't tell whether
++ * this entry should be included. Just fail the whole READDIR
++ * with NFS4ERR_DELAY in that case, and hope that the situation
++ * will resolve itself by the client's next attempt.
++ */
++ if (cd->rd_fhp->fh_export->ex_flags & NFSEXP_V4ROOT)
++ goto fail;
++ fallthrough;
+ default:
+ /*
+ * If the client requested the RDATTR_ERROR attribute,
nvmet-use-nvme_cmd_effects_csupp-instead-of-open-cod.patch
nvme-also-return-i-o-command-effects-from-nvme_comma.patch
btrfs-check-superblock-to-ensure-the-fs-was-not-modi.patch
+x86-kexec-fix-double-free-of-elf-header-buffer.patch
+x86-bugs-flush-ibp-in-ib_prctl_set.patch
+nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch
+fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch
+block-don-t-allow-splitting-of-a-req_nowait-bio.patch
+io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch
+io_uring-fix-cq-waiting-timeout-handling.patch
--- /dev/null
+From a664ec9158eeddd75121d39c9a0758016097fa96 Mon Sep 17 00:00:00 2001
+From: Rodrigo Branco <bsdaemon@google.com>
+Date: Tue, 3 Jan 2023 14:17:51 -0600
+Subject: x86/bugs: Flush IBP in ib_prctl_set()
+
+From: Rodrigo Branco <bsdaemon@google.com>
+
+commit a664ec9158eeddd75121d39c9a0758016097fa96 upstream.
+
+We missed the window between the TIF flag update and the next reschedule.
+
+Signed-off-by: Rodrigo Branco <bsdaemon@google.com>
+Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/bugs.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/cpu/bugs.c
++++ b/arch/x86/kernel/cpu/bugs.c
+@@ -1951,6 +1951,8 @@ static int ib_prctl_set(struct task_stru
+ if (ctrl == PR_SPEC_FORCE_DISABLE)
+ task_set_spec_ib_force_disable(task);
+ task_update_spec_tif(task);
++ if (task == current)
++ indirect_branch_prediction_barrier();
+ break;
+ default:
+ return -ERANGE;
--- /dev/null
+From d00dd2f2645dca04cf399d8fc692f3f69b6dd996 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 22 Nov 2022 12:51:22 +0100
+Subject: x86/kexec: Fix double-free of elf header buffer
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit d00dd2f2645dca04cf399d8fc692f3f69b6dd996 upstream.
+
+After
+
+ b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"),
+
+freeing image->elf_headers in the error path of crash_load_segments()
+is not needed because kimage_file_post_load_cleanup() will take
+care of that later. And not clearing it could result in a double-free.
+
+Drop the superfluous vfree() call at the error path of
+crash_load_segments().
+
+Fixes: b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer")
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: Baoquan He <bhe@redhat.com>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20221122115122.13937-1-tiwai@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/crash.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/crash.c
++++ b/arch/x86/kernel/crash.c
+@@ -401,10 +401,8 @@ int crash_load_segments(struct kimage *i
+ kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
+ kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
+ ret = kexec_add_buffer(&kbuf);
+- if (ret) {
+- vfree((void *)image->elf_headers);
++ if (ret)
+ return ret;
+- }
+ image->elf_load_addr = kbuf.mem;
+ pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
+ image->elf_load_addr, kbuf.bufsz, kbuf.bufsz);
projects / thirdparty / kernel / stable-queue.git / commitdiff
