--- /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 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
+@@ -3405,6 +3405,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,
udf-fix-extension-of-the-last-extent-in-the-file.patch
asoc-intel-bytcr_rt5640-add-quirk-for-the-advantech-.patch
nvme-fix-multipath-crash-caused-by-flush-request-whe.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
+io_uring-io-wq-free-worker-if-task_work-creation-is-canceled.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
+@@ -1896,6 +1896,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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
