From 42f03443bb438872b51ae679b21bca1fd294b15b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 10 Jan 2023 09:13:29 +0100 Subject: [PATCH] 5.15-stable patches added patches: block-don-t-allow-splitting-of-a-req_nowait-bio.patch fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch io_uring-fix-cq-waiting-timeout-handling.patch io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch x86-bugs-flush-ibp-in-ib_prctl_set.patch x86-kexec-fix-double-free-of-elf-header-buffer.patch --- ...-allow-splitting-of-a-req_nowait-bio.patch | 47 +++++++++++++++ ...crease-max-memory-from-1-mb-to-16-mb.patch | 60 +++++++++++++++++++ ...ring-fix-cq-waiting-timeout-handling.patch | 54 +++++++++++++++++ ...er-if-task_work-creation-is-canceled.patch | 34 +++++++++++ ...r-in-v4root-vs.-mount-upcall-timeout.patch | 52 ++++++++++++++++ queue-5.15/series | 7 +++ .../x86-bugs-flush-ibp-in-ib_prctl_set.patch | 31 ++++++++++ ...fix-double-free-of-elf-header-buffer.patch | 46 ++++++++++++++ 8 files changed, 331 insertions(+) create mode 100644 queue-5.15/block-don-t-allow-splitting-of-a-req_nowait-bio.patch create mode 100644 queue-5.15/fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch create mode 100644 queue-5.15/io_uring-fix-cq-waiting-timeout-handling.patch create mode 100644 queue-5.15/io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch create mode 100644 queue-5.15/nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch create mode 100644 queue-5.15/x86-bugs-flush-ibp-in-ib_prctl_set.patch create mode 100644 queue-5.15/x86-kexec-fix-double-free-of-elf-header-buffer.patch diff --git a/queue-5.15/block-don-t-allow-splitting-of-a-req_nowait-bio.patch b/queue-5.15/block-don-t-allow-splitting-of-a-req_nowait-bio.patch new file mode 100644 index 00000000000..c6c32f88abd --- /dev/null +++ b/queue-5.15/block-don-t-allow-splitting-of-a-req_nowait-bio.patch @@ -0,0 +1,47 @@ +From 9cea62b2cbabff8ed46f2df17778b624ad9dd25a Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Wed, 4 Jan 2023 08:52:06 -0700 +Subject: block: don't allow splitting of a REQ_NOWAIT bio + +From: Jens Axboe + +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 +Reviewed-by: Keith Busch +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + 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; + + /* diff --git a/queue-5.15/fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch b/queue-5.15/fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch new file mode 100644 index 00000000000..047ffae4da3 --- /dev/null +++ b/queue-5.15/fbdev-matroxfb-g200ew-increase-max-memory-from-1-mb-to-16-mb.patch @@ -0,0 +1,60 @@ +From f685dd7a8025f2554f73748cfdb8143a21fb92c7 Mon Sep 17 00:00:00 2001 +From: Paul Menzel +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 + +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 +Cc: Rich Felker +Cc: stable@vger.kernel.org +Signed-off-by: Paul Menzel +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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 + }; diff --git a/queue-5.15/io_uring-fix-cq-waiting-timeout-handling.patch b/queue-5.15/io_uring-fix-cq-waiting-timeout-handling.patch new file mode 100644 index 00000000000..8f856af0fe5 --- /dev/null +++ b/queue-5.15/io_uring-fix-cq-waiting-timeout-handling.patch @@ -0,0 +1,54 @@ +From 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8 Mon Sep 17 00:00:00 2001 +From: Pavel Begunkov +Date: Thu, 5 Jan 2023 10:49:15 +0000 +Subject: io_uring: fix CQ waiting timeout handling + +From: Pavel Begunkov + +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 +Link: https://lore.kernel.org/r/f7bffddd71b08f28a877d44d37ac953ddb01590d.1672915663.git.asml.silence@gmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch b/queue-5.15/io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch new file mode 100644 index 00000000000..730e1a6699b --- /dev/null +++ b/queue-5.15/io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.patch @@ -0,0 +1,34 @@ +From af82425c6a2d2f347c79b63ce74fca6dc6be157f Mon Sep 17 00:00:00 2001 +From: Jens Axboe +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 + +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: 진호 +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + } + diff --git a/queue-5.15/nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch b/queue-5.15/nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch new file mode 100644 index 00000000000..3cd66972423 --- /dev/null +++ b/queue-5.15/nfsd-fix-handling-of-readdir-in-v4root-vs.-mount-upcall-timeout.patch @@ -0,0 +1,52 @@ +From cad853374d85fe678d721512cecfabd7636e51f3 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Tue, 13 Dec 2022 13:08:26 -0500 +Subject: nfsd: fix handling of readdir in v4root vs. mount upcall timeout + +From: Jeff Layton + +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 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=216777 +Reported-by: JianHong Yin +Signed-off-by: Jeff Layton +Signed-off-by: Chuck Lever +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.15/series b/queue-5.15/series index e130629312b..37e15bf998a 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -262,3 +262,10 @@ io_uring-check-for-valid-register-opcode-earlier.patch 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 diff --git a/queue-5.15/x86-bugs-flush-ibp-in-ib_prctl_set.patch b/queue-5.15/x86-bugs-flush-ibp-in-ib_prctl_set.patch new file mode 100644 index 00000000000..b4b2c83565b --- /dev/null +++ b/queue-5.15/x86-bugs-flush-ibp-in-ib_prctl_set.patch @@ -0,0 +1,31 @@ +From a664ec9158eeddd75121d39c9a0758016097fa96 Mon Sep 17 00:00:00 2001 +From: Rodrigo Branco +Date: Tue, 3 Jan 2023 14:17:51 -0600 +Subject: x86/bugs: Flush IBP in ib_prctl_set() + +From: Rodrigo Branco + +commit a664ec9158eeddd75121d39c9a0758016097fa96 upstream. + +We missed the window between the TIF flag update and the next reschedule. + +Signed-off-by: Rodrigo Branco +Reviewed-by: Borislav Petkov (AMD) +Signed-off-by: Ingo Molnar +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/x86-kexec-fix-double-free-of-elf-header-buffer.patch b/queue-5.15/x86-kexec-fix-double-free-of-elf-header-buffer.patch new file mode 100644 index 00000000000..1ad22794add --- /dev/null +++ b/queue-5.15/x86-kexec-fix-double-free-of-elf-header-buffer.patch @@ -0,0 +1,46 @@ +From d00dd2f2645dca04cf399d8fc692f3f69b6dd996 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 22 Nov 2022 12:51:22 +0100 +Subject: x86/kexec: Fix double-free of elf header buffer + +From: Takashi Iwai + +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 +Signed-off-by: Borislav Petkov (AMD) +Acked-by: Baoquan He +Acked-by: Vlastimil Babka +Cc: +Link: https://lore.kernel.org/r/20221122115122.13937-1-tiwai@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3