--- /dev/null
+From 3220022038b9a3845eea762af85f1c5694b9f861 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Tue, 11 Oct 2022 20:00:12 +0100
+Subject: ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream.
+
+clang-15's ability to elide loops completely became more aggressive when
+it can deduce how a variable is being updated in a loop. Counting down
+one variable by an increment of another can be replaced by a modulo
+operation.
+
+For 64b variables on 32b ARM EABI targets, this can result in the
+compiler generating calls to __aeabi_uldivmod, which it does for a do
+while loop in float64_rem().
+
+For the kernel, we'd generally prefer that developers not open code 64b
+division via binary / operators and instead use the more explicit
+helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can
+result in linkage failures due to undefined references to
+__aeabi_uldivmod().
+
+While developers can avoid open coding divisions on 64b variables, the
+compiler doesn't know that the Linux kernel has a partial implementation
+of a compiler runtime (--rtlib) to enforce this convention.
+
+It's also undecidable for the compiler whether the code in question
+would be faster to execute the loop vs elide it and do the 64b division.
+
+While I actively avoid using the internal -mllvm command line flags, I
+think we get better code than using barrier() here, which will force
+reloads+spills in the loop for all toolchains.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/1666
+
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/nwfpe/Makefile | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/arm/nwfpe/Makefile
++++ b/arch/arm/nwfpe/Makefile
+@@ -11,3 +11,9 @@ nwfpe-y += fpa11.o fpa11_cpdo.o fpa11
+ entry.o
+
+ nwfpe-$(CONFIG_FPE_NWFPE_XP) += extended_cpdo.o
++
++# Try really hard to avoid generating calls to __aeabi_uldivmod() from
++# float64_rem() due to loop elision.
++ifdef CONFIG_CC_IS_CLANG
++CFLAGS_softfloat.o += -mllvm -replexitval=never
++endif
--- /dev/null
+From e4a4175201014c0222f6bab1895a17b3d1b92f08 Mon Sep 17 00:00:00 2001
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+Date: Fri, 11 Nov 2022 17:55:40 +0800
+Subject: arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon
+
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+
+commit e4a4175201014c0222f6bab1895a17b3d1b92f08 upstream.
+
+The size of device tree node secmon (bl31_secmon_reserved) was
+incorrect. It should be increased to 2MiB (0x200000).
+
+The origin setting will cause some abnormal behavior due to
+trusted-firmware-a and related firmware didn't load correctly.
+The incorrect behavior may vary because of different software stacks.
+For example, it will cause build error in some Yocto project because
+it will check if there was enough memory to load trusted-firmware-a
+to the reserved memory.
+
+When mt8195-demo.dts sent to the upstream, at that time the size of
+BL31 was small. Because supported functions and modules in BL31 are
+basic sets when the board was under early development stage.
+
+Now BL31 includes more firmwares of coprocessors and maturer functions
+so the size has grown bigger in real applications. According to the value
+reported by customers, we think reserved 2MiB for BL31 might be enough
+for maybe the following 2 or 3 years.
+
+Cc: stable@vger.kernel.org # v5.19
+Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board")
+Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
+Reviewed-by: Miles Chen <miles.chen@mediatek.com>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Link: https://lore.kernel.org/r/20221111095540.28881-1-macpaul.lin@mediatek.com
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/boot/dts/mediatek/mt8195-demo.dts b/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
+index 4fbd99eb496a..dec85d254838 100644
+--- a/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
++++ b/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
+@@ -56,10 +56,10 @@ reserved-memory {
+ #size-cells = <2>;
+ ranges;
+
+- /* 192 KiB reserved for ARM Trusted Firmware (BL31) */
++ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ bl31_secmon_reserved: secmon@54600000 {
+ no-map;
+- reg = <0 0x54600000 0x0 0x30000>;
++ reg = <0 0x54600000 0x0 0x200000>;
+ };
+
+ /* 12 MiB reserved for OP-TEE (BL32)
+--
+2.39.0
+
--- /dev/null
+From 015d02f48537cf2d1a65eeac50717566f9db6eec Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Date: Thu, 24 Nov 2022 11:12:08 +0900
+Subject: block: mq-deadline: Do not break sequential write streams to zoned HDDs
+
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+commit 015d02f48537cf2d1a65eeac50717566f9db6eec upstream.
+
+mq-deadline ensures an in order dispatching of write requests to zoned
+block devices using a per zone lock (a bit). This implies that for any
+purely sequential write workload, the drive is exercised most of the
+time at a maximum queue depth of one.
+
+However, when such sequential write workload crosses a zone boundary
+(when sequentially writing multiple contiguous zones), zone write
+locking may prevent the last write to one zone to be issued (as the
+previous write is still being executed) but allow the first write to the
+following zone to be issued (as that zone is not yet being writen and
+not locked). This result in an out of order delivery of the sequential
+write commands to the device every time a zone boundary is crossed.
+
+While such behavior does not break the sequential write constraint of
+zoned block devices (and does not generate any write error), some zoned
+hard-disks react badly to seeing these out of order writes, resulting in
+lower write throughput.
+
+This problem can be addressed by always dispatching the first request
+of a stream of sequential write requests, regardless of the zones
+targeted by these sequential writes. To do so, the function
+deadline_skip_seq_writes() is introduced and used in
+deadline_next_request() to select the next write command to issue if the
+target device is an HDD (blk_queue_nonrot() being false).
+deadline_fifo_request() is modified using the new
+deadline_earlier_request() and deadline_is_seq_write() helpers to ignore
+requests in the fifo list that have a preceding request in lba order
+that is sequential.
+
+With this fix, a sequential write workload executed with the following
+fio command:
+
+fio --name=seq-write --filename=/dev/sda --zonemode=zbd --direct=1 \
+ --size=68719476736 --ioengine=libaio --iodepth=32 --rw=write \
+ --bs=65536
+
+results in an increase from 225 MB/s to 250 MB/s of the write throughput
+of an SMR HDD (11% increase).
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Link: https://lore.kernel.org/r/20221124021208.242541-3-damien.lemoal@opensource.wdc.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/mq-deadline.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++----
+ 1 file changed, 62 insertions(+), 4 deletions(-)
+
+--- a/block/mq-deadline.c
++++ b/block/mq-deadline.c
+@@ -131,6 +131,20 @@ static u8 dd_rq_ioclass(struct request *
+ }
+
+ /*
++ * get the request before `rq' in sector-sorted order
++ */
++static inline struct request *
++deadline_earlier_request(struct request *rq)
++{
++ struct rb_node *node = rb_prev(&rq->rb_node);
++
++ if (node)
++ return rb_entry_rq(node);
++
++ return NULL;
++}
++
++/*
+ * get the request after `rq' in sector-sorted order
+ */
+ static inline struct request *
+@@ -278,6 +292,39 @@ static inline int deadline_check_fifo(st
+ }
+
+ /*
++ * Check if rq has a sequential request preceding it.
++ */
++static bool deadline_is_seq_writes(struct deadline_data *dd, struct request *rq)
++{
++ struct request *prev = deadline_earlier_request(rq);
++
++ if (!prev)
++ return false;
++
++ return blk_rq_pos(prev) + blk_rq_sectors(prev) == blk_rq_pos(rq);
++}
++
++/*
++ * Skip all write requests that are sequential from @rq, even if we cross
++ * a zone boundary.
++ */
++static struct request *deadline_skip_seq_writes(struct deadline_data *dd,
++ struct request *rq)
++{
++ sector_t pos = blk_rq_pos(rq);
++ sector_t skipped_sectors = 0;
++
++ while (rq) {
++ if (blk_rq_pos(rq) != pos + skipped_sectors)
++ break;
++ skipped_sectors += blk_rq_sectors(rq);
++ rq = deadline_latter_request(rq);
++ }
++
++ return rq;
++}
++
++/*
+ * For the specified data direction, return the next request to
+ * dispatch using arrival ordered lists.
+ */
+@@ -297,11 +344,16 @@ deadline_fifo_request(struct deadline_da
+
+ /*
+ * Look for a write request that can be dispatched, that is one with
+- * an unlocked target zone.
++ * an unlocked target zone. For some HDDs, breaking a sequential
++ * write stream can lead to lower throughput, so make sure to preserve
++ * sequential write streams, even if that stream crosses into the next
++ * zones and these zones are unlocked.
+ */
+ spin_lock_irqsave(&dd->zone_lock, flags);
+ list_for_each_entry(rq, &per_prio->fifo_list[DD_WRITE], queuelist) {
+- if (blk_req_can_dispatch_to_zone(rq))
++ if (blk_req_can_dispatch_to_zone(rq) &&
++ (blk_queue_nonrot(rq->q) ||
++ !deadline_is_seq_writes(dd, rq)))
+ goto out;
+ }
+ rq = NULL;
+@@ -331,13 +383,19 @@ deadline_next_request(struct deadline_da
+
+ /*
+ * Look for a write request that can be dispatched, that is one with
+- * an unlocked target zone.
++ * an unlocked target zone. For some HDDs, breaking a sequential
++ * write stream can lead to lower throughput, so make sure to preserve
++ * sequential write streams, even if that stream crosses into the next
++ * zones and these zones are unlocked.
+ */
+ spin_lock_irqsave(&dd->zone_lock, flags);
+ while (rq) {
+ if (blk_req_can_dispatch_to_zone(rq))
+ break;
+- rq = deadline_latter_request(rq);
++ if (blk_queue_nonrot(rq->q))
++ rq = deadline_latter_request(rq);
++ else
++ rq = deadline_skip_seq_writes(dd, rq);
+ }
+ spin_unlock_irqrestore(&dd->zone_lock, flags);
+
--- /dev/null
+From 2820e5d0820ac4daedff1272616a53d9c7682fd2 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Date: Thu, 24 Nov 2022 11:12:07 +0900
+Subject: block: mq-deadline: Fix dd_finish_request() for zoned devices
+
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+commit 2820e5d0820ac4daedff1272616a53d9c7682fd2 upstream.
+
+dd_finish_request() tests if the per prio fifo_list is not empty to
+determine if request dispatching must be restarted for handling blocked
+write requests to zoned devices with a call to
+blk_mq_sched_mark_restart_hctx(). While simple, this implementation has
+2 problems:
+
+1) Only the priority level of the completed request is considered.
+ However, writes to a zone may be blocked due to other writes to the
+ same zone using a different priority level. While this is unlikely to
+ happen in practice, as writing a zone with different IO priorirites
+ does not make sense, nothing in the code prevents this from
+ happening.
+2) The use of list_empty() is dangerous as dd_finish_request() does not
+ take dd->lock and may run concurrently with the insert and dispatch
+ code.
+
+Fix these 2 problems by testing the write fifo list of all priority
+levels using the new helper dd_has_write_work(), and by testing each
+fifo list using list_empty_careful().
+
+Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Link: https://lore.kernel.org/r/20221124021208.242541-2-damien.lemoal@opensource.wdc.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/mq-deadline.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+--- a/block/mq-deadline.c
++++ b/block/mq-deadline.c
+@@ -789,6 +789,18 @@ static void dd_prepare_request(struct re
+ rq->elv.priv[0] = NULL;
+ }
+
++static bool dd_has_write_work(struct blk_mq_hw_ctx *hctx)
++{
++ struct deadline_data *dd = hctx->queue->elevator->elevator_data;
++ enum dd_prio p;
++
++ for (p = 0; p <= DD_PRIO_MAX; p++)
++ if (!list_empty_careful(&dd->per_prio[p].fifo_list[DD_WRITE]))
++ return true;
++
++ return false;
++}
++
+ /*
+ * Callback from inside blk_mq_free_request().
+ *
+@@ -828,9 +840,10 @@ static void dd_finish_request(struct req
+
+ spin_lock_irqsave(&dd->zone_lock, flags);
+ blk_req_zone_write_unlock(rq);
+- if (!list_empty(&per_prio->fifo_list[DD_WRITE]))
+- blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
+ spin_unlock_irqrestore(&dd->zone_lock, flags);
++
++ if (dd_has_write_work(rq->mq_hctx))
++ blk_mq_sched_mark_restart_hctx(rq->mq_hctx);
+ }
+ }
+
--- /dev/null
+From a85ceafd41927e41a4103d228a993df7edd8823b Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Fri, 16 Dec 2022 22:03:41 -0300
+Subject: cifs: fix confusing debug message
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit a85ceafd41927e41a4103d228a993df7edd8823b upstream.
+
+Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an
+existing smb session was found, free_xid() would be called and then
+print
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12
+
+Fix this by initialising rc to 0 and then let free_xid() print this
+instead
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0
+
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -2155,7 +2155,7 @@ cifs_set_cifscreds(struct smb3_fs_contex
+ struct cifs_ses *
+ cifs_get_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx)
+ {
+- int rc = -ENOMEM;
++ int rc = 0;
+ unsigned int xid;
+ struct cifs_ses *ses;
+ struct sockaddr_in *addr = (struct sockaddr_in *)&server->dstaddr;
+@@ -2204,6 +2204,8 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ return ses;
+ }
+
++ rc = -ENOMEM;
++
+ cifs_dbg(FYI, "Existing smb sess not found\n");
+ ses = sesInfoAlloc();
+ if (ses == NULL)
--- /dev/null
+From 2bfd81043e944af0e52835ef6d9b41795af22341 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Sun, 11 Dec 2022 13:54:21 -0600
+Subject: cifs: fix missing display of three mount options
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 2bfd81043e944af0e52835ef6d9b41795af22341 upstream.
+
+Three mount options: "tcpnodelay" and "noautotune" and "noblocksend"
+were not displayed when passed in on cifs/smb3 mounts (e.g. displayed
+in /proc/mounts e.g.). No change to defaults so these are not
+displayed if not specified on mount.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/cifsfs.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -678,9 +678,15 @@ cifs_show_options(struct seq_file *s, st
+ seq_printf(s, ",echo_interval=%lu",
+ tcon->ses->server->echo_interval / HZ);
+
+- /* Only display max_credits if it was overridden on mount */
++ /* Only display the following if overridden on mount */
+ if (tcon->ses->server->max_credits != SMB2_MAX_CREDITS_AVAILABLE)
+ seq_printf(s, ",max_credits=%u", tcon->ses->server->max_credits);
++ if (tcon->ses->server->tcp_nodelay)
++ seq_puts(s, ",tcpnodelay");
++ if (tcon->ses->server->noautotune)
++ seq_puts(s, ",noautotune");
++ if (tcon->ses->server->noblocksnd)
++ seq_puts(s, ",noblocksend");
+
+ if (tcon->snapshot_time)
+ seq_printf(s, ",snapshot=%llu", tcon->snapshot_time);
--- /dev/null
+From 86fe0fa8747fb1bc4cc44fc1966e0959fe752f38 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Fri, 16 Dec 2022 14:00:19 -0300
+Subject: cifs: set correct ipc status after initial tree connect
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit 86fe0fa8747fb1bc4cc44fc1966e0959fe752f38 upstream.
+
+cifs_tcon::status wasn't correctly updated to TID_GOOD after
+establishing initial IPC connection thus staying at TID_NEW as long as
+it wasn't reconnected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -1870,6 +1870,9 @@ cifs_setup_ipc(struct cifs_ses *ses, str
+
+ cifs_dbg(FYI, "IPC tcon rc=%d ipc tid=0x%x\n", rc, tcon->tid);
+
++ spin_lock(&tcon->tc_lock);
++ tcon->status = TID_GOOD;
++ spin_unlock(&tcon->tc_lock);
+ ses->tcon_ipc = tcon;
+ out:
+ return rc;
+@@ -2278,10 +2281,10 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ list_add(&ses->smb_ses_list, &server->smb_ses_list);
+ spin_unlock(&cifs_tcp_ses_lock);
+
+- free_xid(xid);
+-
+ cifs_setup_ipc(ses, ctx);
+
++ free_xid(xid);
++
+ return ses;
+
+ get_ses_fail:
--- /dev/null
+From 25cf01b7c9200d6ace5a59125d8166435dd9dea7 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Sat, 17 Dec 2022 21:04:14 -0300
+Subject: cifs: set correct status of tcon ipc when reconnecting
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit 25cf01b7c9200d6ace5a59125d8166435dd9dea7 upstream.
+
+The status of tcon ipcs were not being set to TID_NEED_RECO when
+marking sessions and tcons to be reconnected, therefore not sending
+tree connect to those ipcs in cifs_tree_connect() and leaving them
+disconnected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -279,8 +279,10 @@ cifs_mark_tcp_ses_conns_for_reconnect(st
+ tcon->need_reconnect = true;
+ tcon->status = TID_NEED_RECON;
+ }
+- if (ses->tcon_ipc)
++ if (ses->tcon_ipc) {
+ ses->tcon_ipc->need_reconnect = true;
++ ses->tcon_ipc->status = TID_NEED_RECON;
++ }
+
+ next_session:
+ spin_unlock(&ses->chan_lock);
--- /dev/null
+From b248586a49a7729f73c504b1e7b958caea45e927 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Tue, 13 Dec 2022 09:15:23 -0300
+Subject: cifs: set correct tcon status after initial tree connect
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit b248586a49a7729f73c504b1e7b958caea45e927 upstream.
+
+cifs_tcon::status wasn't correctly updated to TID_GOOD after initial
+tree connect thus staying at TID_NEW as long as it was connected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -2600,6 +2600,7 @@ cifs_get_tcon(struct cifs_ses *ses, stru
+ tcon->nodelete = ctx->nodelete;
+ tcon->local_lease = ctx->local_lease;
+ INIT_LIST_HEAD(&tcon->pending_opens);
++ tcon->status = TID_GOOD;
+
+ /* schedule query interfaces poll */
+ INIT_DELAYED_WORK(&tcon->query_interfaces,
--- /dev/null
+From 347fafe0eb46df941965c355c77ce480e4d49f1f Mon Sep 17 00:00:00 2001
+From: Yang Wang <KevinYang.Wang@amd.com>
+Date: Mon, 5 Dec 2022 21:16:26 +0800
+Subject: drm/amdgpu: fix mmhub register base coding error
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yang Wang <KevinYang.Wang@amd.com>
+
+commit 347fafe0eb46df941965c355c77ce480e4d49f1f upstream.
+
+fix MMHUB register base coding error.
+
+Fixes: ec6837591f992 ("drm/amdgpu/gmc10: program the smallK fragment size")
+
+Signed-off-by: Yang Wang <KevinYang.Wang@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 2 +-
+ drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 2 +-
+ drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c | 2 +-
+ drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c | 2 +-
+ drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c | 2 +-
+ 5 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c
+@@ -319,7 +319,7 @@ static void mmhub_v2_0_init_cache_regs(s
+
+ tmp = mmMMVM_L2_CNTL5_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, MMVM_L2_CNTL5, L2_CACHE_SMALLK_FRAGMENT_SIZE, 0);
+- WREG32_SOC15(GC, 0, mmMMVM_L2_CNTL5, tmp);
++ WREG32_SOC15(MMHUB, 0, mmMMVM_L2_CNTL5, tmp);
+ }
+
+ static void mmhub_v2_0_enable_system_domain(struct amdgpu_device *adev)
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
+@@ -243,7 +243,7 @@ static void mmhub_v2_3_init_cache_regs(s
+
+ tmp = mmMMVM_L2_CNTL5_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, MMVM_L2_CNTL5, L2_CACHE_SMALLK_FRAGMENT_SIZE, 0);
+- WREG32_SOC15(GC, 0, mmMMVM_L2_CNTL5, tmp);
++ WREG32_SOC15(MMHUB, 0, mmMMVM_L2_CNTL5, tmp);
+ }
+
+ static void mmhub_v2_3_enable_system_domain(struct amdgpu_device *adev)
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
+@@ -275,7 +275,7 @@ static void mmhub_v3_0_init_cache_regs(s
+
+ tmp = regMMVM_L2_CNTL5_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, MMVM_L2_CNTL5, L2_CACHE_SMALLK_FRAGMENT_SIZE, 0);
+- WREG32_SOC15(GC, 0, regMMVM_L2_CNTL5, tmp);
++ WREG32_SOC15(MMHUB, 0, regMMVM_L2_CNTL5, tmp);
+ }
+
+ static void mmhub_v3_0_enable_system_domain(struct amdgpu_device *adev)
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
+@@ -269,7 +269,7 @@ static void mmhub_v3_0_1_init_cache_regs
+
+ tmp = regMMVM_L2_CNTL5_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, MMVM_L2_CNTL5, L2_CACHE_SMALLK_FRAGMENT_SIZE, 0);
+- WREG32_SOC15(GC, 0, regMMVM_L2_CNTL5, tmp);
++ WREG32_SOC15(MMHUB, 0, regMMVM_L2_CNTL5, tmp);
+ }
+
+ static void mmhub_v3_0_1_enable_system_domain(struct amdgpu_device *adev)
+--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c
++++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c
+@@ -268,7 +268,7 @@ static void mmhub_v3_0_2_init_cache_regs
+
+ tmp = regMMVM_L2_CNTL5_DEFAULT;
+ tmp = REG_SET_FIELD(tmp, MMVM_L2_CNTL5, L2_CACHE_SMALLK_FRAGMENT_SIZE, 0);
+- WREG32_SOC15(GC, 0, regMMVM_L2_CNTL5, tmp);
++ WREG32_SOC15(MMHUB, 0, regMMVM_L2_CNTL5, tmp);
+ }
+
+ static void mmhub_v3_0_2_enable_system_domain(struct amdgpu_device *adev)
--- /dev/null
+From fd3dc56253acbe9c641a66d312d8393cd55eb04c Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Fri, 9 Dec 2022 10:52:47 -0500
+Subject: ftrace/x86: Add back ftrace_expected for ftrace bug reports
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit fd3dc56253acbe9c641a66d312d8393cd55eb04c upstream.
+
+After someone reported a bug report with a failed modification due to the
+expected value not matching what was found, it came to my attention that
+the ftrace_expected is no longer set when that happens. This makes for
+debugging the issue a bit more difficult.
+
+Set ftrace_expected to the expected code before calling ftrace_bug, so
+that it shows what was expected and why it failed.
+
+Link: https://lore.kernel.org/all/CA+wXwBQ-VhK+hpBtYtyZP-NiX4g8fqRRWithFOHQW-0coQ3vLg@mail.gmail.com/
+Link: https://lore.kernel.org/linux-trace-kernel/20221209105247.01d4e51d@gandalf.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: "x86@kernel.org" <x86@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/ftrace.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -217,7 +217,9 @@ void ftrace_replace_code(int enable)
+
+ ret = ftrace_verify_code(rec->ip, old);
+ if (ret) {
++ ftrace_expected = old;
+ ftrace_bug(ret, rec);
++ ftrace_expected = NULL;
+ return;
+ }
+ }
--- /dev/null
+From 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 6 Oct 2022 00:19:56 +0000
+Subject: KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream.
+
+Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the
+generic "is CRx valid" check, but passes the CR4.VMXE check, and do the
+generic checks _after_ handling the post-VMXON VM-Fail.
+
+The CR4.VMXE check, and all other #UD cases, are special pre-conditions
+that are enforced prior to pivoting on the current VMX mode, i.e. occur
+before interception if VMXON is attempted in VMX non-root mode.
+
+All other CR0/CR4 checks generate #GP and effectively have lower priority
+than the post-VMXON check.
+
+Per the SDM:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD;
+ ELSIF not in VMX operation
+ THEN
+ IF (CPL > 0) or (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+ ELSIF in VMX non-root operation
+ THEN VMexit;
+ ELSIF CPL > 0
+ THEN #GP(0);
+ ELSE VMfail("VMXON executed in VMX root operation");
+ FI;
+
+which, if re-written without ELSIF, yields:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD
+
+ IF in VMX non-root operation
+ THEN VMexit;
+
+ IF CPL > 0
+ THEN #GP(0)
+
+ IF in VMX operation
+ THEN VMfail("VMXON executed in VMX root operation");
+
+ IF (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+
+Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1,
+i.e. there is no need to check the vCPU is not in VMX non-root mode. Add
+a comment to explain why unconditionally forwarding such exits is
+functionally correct.
+
+Reported-by: Eric Li <ercli@ucdavis.edu>
+Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 44 +++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 33 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -4953,24 +4953,35 @@ static int handle_vmxon(struct kvm_vcpu
+ | FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX;
+
+ /*
+- * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks
+- * that have higher priority than VM-Exit (see Intel SDM's pseudocode
+- * for VMXON), as KVM must load valid CR0/CR4 values into hardware while
+- * running the guest, i.e. KVM needs to check the _guest_ values.
++ * Manually check CR4.VMXE checks, KVM must force CR4.VMXE=1 to enter
++ * the guest and so cannot rely on hardware to perform the check,
++ * which has higher priority than VM-Exit (see Intel SDM's pseudocode
++ * for VMXON).
+ *
+- * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and
+- * !COMPATIBILITY modes. KVM may run the guest in VM86 to emulate Real
+- * Mode, but KVM will never take the guest out of those modes.
++ * Rely on hardware for the other pre-VM-Exit checks, CR0.PE=1, !VM86
++ * and !COMPATIBILITY modes. For an unrestricted guest, KVM doesn't
++ * force any of the relevant guest state. For a restricted guest, KVM
++ * does force CR0.PE=1, but only to also force VM86 in order to emulate
++ * Real Mode, and so there's no need to check CR0.PE manually.
+ */
+- if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
+- !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
+
+ /*
+- * CPL=0 and all other checks that are lower priority than VM-Exit must
+- * be checked manually.
++ * The CPL is checked for "not in VMX operation" and for "in VMX root",
++ * and has higher priority than the VM-Fail due to being post-VMXON,
++ * i.e. VMXON #GPs outside of VMX non-root if CPL!=0. In VMX non-root,
++ * VMXON causes VM-Exit and KVM unconditionally forwards VMXON VM-Exits
++ * from L2 to L1, i.e. there's no need to check for the vCPU being in
++ * VMX non-root.
++ *
++ * Forwarding the VM-Exit unconditionally, i.e. without performing the
++ * #UD checks (see above), is functionally ok because KVM doesn't allow
++ * L1 to run L2 without CR4.VMXE=0, and because KVM never modifies L2's
++ * CR0 or CR4, i.e. it's L2's responsibility to emulate #UDs that are
++ * missed by hardware due to shadowing CR0 and/or CR4.
+ */
+ if (vmx_get_cpl(vcpu)) {
+ kvm_inject_gp(vcpu, 0);
+@@ -4980,6 +4991,17 @@ static int handle_vmxon(struct kvm_vcpu
+ if (vmx->nested.vmxon)
+ return nested_vmx_fail(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
+
++ /*
++ * Invalid CR0/CR4 generates #GP. These checks are performed if and
++ * only if the vCPU isn't already in VMX operation, i.e. effectively
++ * have lower priority than the VM-Fail above.
++ */
++ if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
++ !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ kvm_inject_gp(vcpu, 0);
++ return 1;
++ }
++
+ if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES)
+ != VMXON_NEEDED_FEATURES) {
+ kvm_inject_gp(vcpu, 0);
--- /dev/null
+From 31de69f4eea77b28a9724b3fa55aae104fc91fc7 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 13 Dec 2022 06:23:03 +0000
+Subject: KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 31de69f4eea77b28a9724b3fa55aae104fc91fc7 upstream.
+
+Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the
+feature is supported in hardware and enabled in KVM's base, non-nested
+configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported.
+This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail
+if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and
+obviously allows L1 to enable the feature for L2.
+
+KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing
+the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when
+updating secondary controls in response to KVM_SET_CPUID(2), but (a) that
+depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID
+updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction
+that the guest value must be a strict subset of the supported host value.
+
+Although no past commit explicitly enabled nested support for WAITPKG,
+doing so is safe and functionally correct from an architectural
+perspective as no additional KVM support is needed to virtualize TPAUSE,
+UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards
+VM-Exits to L1 as necessary (commit bf653b78f960, "KVM: vmx: Introduce
+handle_unexpected_vmexit and handle WAITPKG vmexit").
+
+Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in
+hardware, i.e. always runs both L1 and L2 with the host's power management
+settings for TPAUSE and UMWAIT. See commit bf09fb6cba4f ("KVM: VMX: Stop
+context switching MSR_IA32_UMWAIT_CONTROL") for more details.
+
+Fixes: e69e72faa3a0 ("KVM: x86: Add support for user wait instructions")
+Cc: stable@vger.kernel.org
+Reported-by: Aaron Lewis <aaronlewis@google.com>
+Reported-by: Yu Zhang <yu.c.zhang@linux.intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Message-Id: <20221213062306.667649-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -6685,7 +6685,8 @@ void nested_vmx_setup_ctls_msrs(struct n
+ SECONDARY_EXEC_ENABLE_INVPCID |
+ SECONDARY_EXEC_RDSEED_EXITING |
+ SECONDARY_EXEC_XSAVES |
+- SECONDARY_EXEC_TSC_SCALING;
++ SECONDARY_EXEC_TSC_SCALING |
++ SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE;
+
+ /*
+ * We can emulate "VMCS shadowing," even if the hardware
--- /dev/null
+From eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Fri, 30 Sep 2022 23:31:32 +0000
+Subject: KVM: VMX: Resume guest immediately when injecting #GP on ECREATE
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 upstream.
+
+Resume the guest immediately when injecting a #GP on ECREATE due to an
+invalid enclave size, i.e. don't attempt ECREATE in the host. The #GP is
+a terminal fault, e.g. skipping the instruction if ECREATE is successful
+would result in KVM injecting #GP on the instruction following ECREATE.
+
+Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
+Cc: stable@vger.kernel.org
+Cc: Kai Huang <kai.huang@intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Link: https://lore.kernel.org/r/20220930233132.1723330-1-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/sgx.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/sgx.c
++++ b/arch/x86/kvm/vmx/sgx.c
+@@ -182,8 +182,10 @@ static int __handle_encls_ecreate(struct
+ /* Enforce CPUID restriction on max enclave size. */
+ max_size_log2 = (attributes & SGX_ATTR_MODE64BIT) ? sgx_12_0->edx >> 8 :
+ sgx_12_0->edx;
+- if (size >= BIT_ULL(max_size_log2))
++ if (size >= BIT_ULL(max_size_log2)) {
+ kvm_inject_gp(vcpu, 0);
++ return 1;
++ }
+
+ /*
+ * sgx_virt_ecreate() returns:
--- /dev/null
+From ef40757743b47cc95de9b4ed41525c94f8dc73d9 Mon Sep 17 00:00:00 2001
+From: Yuan ZhaoXiong <yuanzhaoxiong@baidu.com>
+Date: Fri, 2 Dec 2022 20:36:14 +0800
+Subject: KVM: x86: fix APICv/x2AVIC disabled when vm reboot by itself
+
+From: Yuan ZhaoXiong <yuanzhaoxiong@baidu.com>
+
+commit ef40757743b47cc95de9b4ed41525c94f8dc73d9 upstream.
+
+When a VM reboots itself, the reset process will result in
+an ioctl(KVM_SET_LAPIC, ...) to disable x2APIC mode and set
+the xAPIC id of the vCPU to its default value, which is the
+vCPU id.
+
+That will be handled in KVM as follows:
+
+ kvm_vcpu_ioctl_set_lapic
+ kvm_apic_set_state
+ kvm_lapic_set_base => disable X2APIC mode
+ kvm_apic_state_fixup
+ kvm_lapic_xapic_id_updated
+ kvm_xapic_id(apic) != apic->vcpu->vcpu_id
+ kvm_set_apicv_inhibit(APICV_INHIBIT_REASON_APIC_ID_MODIFIED)
+ memcpy(vcpu->arch.apic->regs, s->regs, sizeof(*s)) => update APIC_ID
+
+When kvm_apic_set_state invokes kvm_lapic_set_base to disable
+x2APIC mode, the old 32-bit x2APIC id is still present rather
+than the 8-bit xAPIC id. kvm_lapic_xapic_id_updated will set the
+APICV_INHIBIT_REASON_APIC_ID_MODIFIED bit and disable APICv/x2AVIC.
+
+Instead, kvm_lapic_xapic_id_updated must be called after APIC_ID is
+changed.
+
+In fact, this fixes another small issue in the code in that
+potential changes to a vCPU's xAPIC ID need not be tracked for
+KVM_GET_LAPIC.
+
+Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base")
+Signed-off-by: Yuan ZhaoXiong <yuanzhaoxiong@baidu.com>
+Message-Id: <1669984574-32692-1-git-send-email-yuanzhaoxiong@baidu.com>
+Cc: stable@vger.kernel.org
+Reported-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2722,8 +2722,6 @@ static int kvm_apic_state_fixup(struct k
+ icr = __kvm_lapic_get_reg64(s->regs, APIC_ICR);
+ __kvm_lapic_set_reg(s->regs, APIC_ICR2, icr >> 32);
+ }
+- } else {
+- kvm_lapic_xapic_id_updated(vcpu->arch.apic);
+ }
+
+ return 0;
+@@ -2759,6 +2757,9 @@ int kvm_apic_set_state(struct kvm_vcpu *
+ }
+ memcpy(vcpu->arch.apic->regs, s->regs, sizeof(*s));
+
++ if (!apic_x2apic_mode(apic))
++ kvm_lapic_xapic_id_updated(apic);
++
+ atomic_set_release(&apic->vcpu->kvm->arch.apic_map_dirty, DIRTY);
+ kvm_recalculate_apic_map(vcpu->kvm);
+ kvm_apic_set_version(vcpu);
--- /dev/null
+From 6b0d0477fce747d4137aa65856318b55fba72198 Mon Sep 17 00:00:00 2001
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Date: Tue, 26 Apr 2022 06:29:19 +0100
+Subject: media: dvb-core: Fix double free in dvb_register_device()
+
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+
+commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream.
+
+In function dvb_register_device() -> dvb_register_media_device() ->
+dvb_create_media_entity(), dvb->entity is allocated and initialized. If
+the initialization fails, it frees the dvb->entity, and return an error
+code. The caller takes the error code and handles the error by calling
+dvb_media_device_free(), which unregisters the entity and frees the
+field again if it is not NULL. As dvb->entity may not NULLed in
+dvb_create_media_entity() when the allocation of dvbdev->pad fails, a
+double free may occur. This may also cause an Use After free in
+media_device_unregister_entity().
+
+Fix this by storing NULL to dvb->entity when it is freed.
+
+Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp
+Fixes: fcd5ce4b3936 ("media: dvb-core: fix a memory leak bug")
+Cc: stable@vger.kernel.org
+Cc: Wenwen Wang <wenwen@cs.uga.edu>
+Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dvbdev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/dvb-core/dvbdev.c
++++ b/drivers/media/dvb-core/dvbdev.c
+@@ -335,6 +335,7 @@ static int dvb_create_media_entity(struc
+ GFP_KERNEL);
+ if (!dvbdev->pads) {
+ kfree(dvbdev->entity);
++ dvbdev->entity = NULL;
+ return -ENOMEM;
+ }
+ }
--- /dev/null
+From fd3d91ab1c6ab0628fe642dd570b56302c30a792 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 31 Oct 2022 11:02:45 +0100
+Subject: media: dvb-core: Fix UAF due to refcount races at releasing
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream.
+
+The dvb-core tries to sync the releases of opened files at
+dvb_dmxdev_release() with two refcounts: dvbdev->users and
+dvr_dvbdev->users. A problem is present in those two syncs: when yet
+another dvb_demux_open() is called during those sync waits,
+dvb_demux_open() continues to process even if the device is being
+closed. This includes the increment of the former refcount, resulting
+in the leftover refcount after the sync of the latter refcount at
+dvb_dmxdev_release(). It ends up with use-after-free, since the
+function believes that all usages were gone and releases the
+resources.
+
+This patch addresses the problem by adding the check of dmxdev->exit
+flag at dvb_demux_open(), just like dvb_dvr_open() already does. With
+the exit flag check, the second call of dvb_demux_open() fails, hence
+the further corruption can be avoided.
+
+Also for avoiding the races of the dmxdev->exit flag reference, this
+patch serializes the dmxdev->exit set up and the sync waits with the
+dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock,
+dvb_demux_open() (or dvb_dvr_open()) may run concurrently with
+dvb_dmxdev_release(), which allows to skip the exit flag check and
+continue the open process that is being closed.
+
+CVE-2022-41218 is assigned to those bugs above.
+
+Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dmxdev.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/media/dvb-core/dmxdev.c
++++ b/drivers/media/dvb-core/dmxdev.c
+@@ -790,6 +790,11 @@ static int dvb_demux_open(struct inode *
+ if (mutex_lock_interruptible(&dmxdev->mutex))
+ return -ERESTARTSYS;
+
++ if (dmxdev->exit) {
++ mutex_unlock(&dmxdev->mutex);
++ return -ENODEV;
++ }
++
+ for (i = 0; i < dmxdev->filternum; i++)
+ if (dmxdev->filter[i].state == DMXDEV_STATE_FREE)
+ break;
+@@ -1448,7 +1453,10 @@ EXPORT_SYMBOL(dvb_dmxdev_init);
+
+ void dvb_dmxdev_release(struct dmxdev *dmxdev)
+ {
++ mutex_lock(&dmxdev->mutex);
+ dmxdev->exit = 1;
++ mutex_unlock(&dmxdev->mutex);
++
+ if (dmxdev->dvbdev->users > 1) {
+ wait_event(dmxdev->dvbdev->wait_queue,
+ dmxdev->dvbdev->users == 1);
--- /dev/null
+From ad050d2390fccb22aa3e6f65e11757ce7a5a7ca5 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson <mjeanson@efficios.com>
+Date: Thu, 1 Dec 2022 11:14:42 -0500
+Subject: powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
+
+From: Michael Jeanson <mjeanson@efficios.com>
+
+commit ad050d2390fccb22aa3e6f65e11757ce7a5a7ca5 upstream.
+
+In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
+PPC64_ELF_ABI_V1 this resulted in the symbols in the syscall table
+changing from their dot prefixed variant to the non-prefixed ones.
+
+Since ftrace prefixes a dot to the syscall names when matching them to
+build its syscall event list, this resulted in no syscall events being
+available.
+
+Remove the PPC64_ELF_ABI_V1 specific version of
+arch_syscall_match_sym_name to have the same behavior across all powerpc
+variants.
+
+Fixes: 68b34588e202 ("powerpc/64/sycall: Implement syscall entry/exit logic in C")
+Cc: stable@vger.kernel.org # v5.7+
+Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
+Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20221201161442.2127231-1-mjeanson@efficios.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/include/asm/ftrace.h | 12 ------------
+ 1 file changed, 12 deletions(-)
+
+--- a/arch/powerpc/include/asm/ftrace.h
++++ b/arch/powerpc/include/asm/ftrace.h
+@@ -64,17 +64,6 @@ void ftrace_graph_func(unsigned long ip,
+ * those.
+ */
+ #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+-#ifdef CONFIG_PPC64_ELF_ABI_V1
+-static inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
+-{
+- /* We need to skip past the initial dot, and the __se_sys alias */
+- return !strcmp(sym + 1, name) ||
+- (!strncmp(sym, ".__se_sys", 9) && !strcmp(sym + 6, name)) ||
+- (!strncmp(sym, ".ppc_", 5) && !strcmp(sym + 5, name + 4)) ||
+- (!strncmp(sym, ".ppc32_", 7) && !strcmp(sym + 7, name + 4)) ||
+- (!strncmp(sym, ".ppc64_", 7) && !strcmp(sym + 7, name + 4));
+-}
+-#else
+ static inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
+ {
+ return !strcmp(sym, name) ||
+@@ -83,7 +72,6 @@ static inline bool arch_syscall_match_sy
+ (!strncmp(sym, "ppc32_", 6) && !strcmp(sym + 6, name + 4)) ||
+ (!strncmp(sym, "ppc64_", 6) && !strcmp(sym + 6, name + 4));
+ }
+-#endif /* CONFIG_PPC64_ELF_ABI_V1 */
+ #endif /* CONFIG_FTRACE_SYSCALLS */
+
+ #if defined(CONFIG_PPC64) && defined(CONFIG_FUNCTION_TRACER)
--- /dev/null
+From c72a7e42592b2e18d862cf120876070947000d7a Mon Sep 17 00:00:00 2001
+From: Biju Das <biju.das.jz@bp.renesas.com>
+Date: Wed, 14 Dec 2022 10:51:18 +0000
+Subject: ravb: Fix "failed to switch device to config mode" message during unbind
+
+From: Biju Das <biju.das.jz@bp.renesas.com>
+
+commit c72a7e42592b2e18d862cf120876070947000d7a upstream.
+
+This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
+device to config mode" during unbind.
+
+We are doing register access after pm_runtime_put_sync().
+
+We usually do cleanup in reverse order of init. Currently in
+remove(), the "pm_runtime_put_sync" is not in reverse order.
+
+Probe
+ reset_control_deassert(rstc);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
+remove
+ pm_runtime_put_sync(&pdev->dev);
+ unregister_netdev(ndev);
+ ..
+ ravb_mdio_release(priv);
+ pm_runtime_disable(&pdev->dev);
+
+Consider the call to unregister_netdev()
+unregister_netdev->unregister_netdevice_queue->rollback_registered_many
+that calls the below functions which access the registers after
+pm_runtime_put_sync()
+ 1) ravb_get_stats
+ 2) ravb_close
+
+Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
+Cc: stable@vger.kernel.org
+Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/renesas/ravb_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/renesas/ravb_main.c
++++ b/drivers/net/ethernet/renesas/ravb_main.c
+@@ -2896,12 +2896,12 @@ static int ravb_remove(struct platform_d
+ priv->desc_bat_dma);
+ /* Set reset mode */
+ ravb_write(ndev, CCC_OPC_RESET, CCC);
+- pm_runtime_put_sync(&pdev->dev);
+ unregister_netdev(ndev);
+ if (info->nc_queues)
+ netif_napi_del(&priv->napi[RAVB_NC]);
+ netif_napi_del(&priv->napi[RAVB_BE]);
+ ravb_mdio_release(priv);
++ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ reset_control_assert(priv->rstc);
+ free_netdev(ndev);
--- /dev/null
+From 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Thu, 27 Oct 2022 17:32:49 +0100
+Subject: rtc: ds1347: fix value written to century register
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 upstream.
+
+In `ds1347_set_time()`, the wrong value is being written to the
+`DS1347_CENTURY_REG` register. It needs to be converted to BCD. Fix
+it.
+
+Fixes: 147dae76dbb9 ("rtc: ds1347: handle century register")
+Cc: <stable@vger.kernel.org> # v5.5+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20221027163249.447416-1-abbotti@mev.co.uk
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-ds1347.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/rtc/rtc-ds1347.c
++++ b/drivers/rtc/rtc-ds1347.c
+@@ -112,7 +112,7 @@ static int ds1347_set_time(struct device
+ return err;
+
+ century = (dt->tm_year / 100) + 19;
+- err = regmap_write(map, DS1347_CENTURY_REG, century);
++ err = regmap_write(map, DS1347_CENTURY_REG, bin2bcd(century));
+ if (err)
+ return err;
+
xtensa-add-__umulsidi3-helper.patch
of-kexec-fix-reading-32-bit-linux-initrd-start-end-values.patch
ima-fix-hash-dependency-to-correct-algorithm.patch
+kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch
+kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch
+kvm-x86-fix-apicv-x2avic-disabled-when-vm-reboot-by-itself.patch
+kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch
+x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch
+ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch
+x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch
+x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch
+tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch
+powerpc-ftrace-fix-syscall-tracing-on-ppc64_elf_abi_v1.patch
+tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch
+tracing-hist-fix-wrong-return-value-in-parse_action_params.patch
+tracing-probes-handle-system-names-with-hyphens.patch
+tracing-fix-issue-of-missing-one-synthetic-field.patch
+tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch
+staging-media-tegra-video-fix-chan-mipi-value-on-error.patch
+staging-media-tegra-video-fix-device_node-use-after-free.patch
+arm64-dts-mediatek-mt8195-demo-fix-the-memory-size-of-node-secmon.patch
+arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch
+media-dvb-core-fix-double-free-in-dvb_register_device.patch
+media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch
+cifs-fix-confusing-debug-message.patch
+cifs-fix-missing-display-of-three-mount-options.patch
+cifs-set-correct-tcon-status-after-initial-tree-connect.patch
+cifs-set-correct-ipc-status-after-initial-tree-connect.patch
+cifs-set-correct-status-of-tcon-ipc-when-reconnecting.patch
+ravb-fix-failed-to-switch-device-to-config-mode-message-during-unbind.patch
+rtc-ds1347-fix-value-written-to-century-register.patch
+drm-amdgpu-fix-mmhub-register-base-coding-error.patch
+block-mq-deadline-fix-dd_finish_request-for-zoned-devices.patch
+block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch
--- /dev/null
+From 10b5ce6743c839fa75336042c64e2479caec9430 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Wed, 2 Nov 2022 12:01:01 +0100
+Subject: staging: media: tegra-video: fix chan->mipi value on error
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit 10b5ce6743c839fa75336042c64e2479caec9430 upstream.
+
+chan->mipi takes the return value of tegra_mipi_request() which can be a
+valid pointer or an error. However chan->mipi is checked in several places,
+including error-cleanup code in tegra_csi_channels_cleanup(), as 'if
+(chan->mipi)', which suggests the initial intent was that chan->mipi should
+be either NULL or a valid pointer, never an error. As a consequence,
+cleanup code in case of tegra_mipi_request() errors would dereference an
+invalid pointer.
+
+Fix by ensuring chan->mipi always contains either NULL or a void pointer.
+
+Also add that to the documentation.
+
+Fixes: 523c857e34ce ("media: tegra-video: Add CSI MIPI pads calibration")
+Cc: stable@vger.kernel.org
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/media/tegra-video/csi.c | 1 +
+ drivers/staging/media/tegra-video/csi.h | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/media/tegra-video/csi.c
++++ b/drivers/staging/media/tegra-video/csi.c
+@@ -448,6 +448,7 @@ static int tegra_csi_channel_alloc(struc
+ chan->mipi = tegra_mipi_request(csi->dev, node);
+ if (IS_ERR(chan->mipi)) {
+ ret = PTR_ERR(chan->mipi);
++ chan->mipi = NULL;
+ dev_err(csi->dev, "failed to get mipi device: %d\n", ret);
+ }
+
+--- a/drivers/staging/media/tegra-video/csi.h
++++ b/drivers/staging/media/tegra-video/csi.h
+@@ -56,7 +56,7 @@ struct tegra_csi;
+ * @framerate: active framerate for TPG
+ * @h_blank: horizontal blanking for TPG active format
+ * @v_blank: vertical blanking for TPG active format
+- * @mipi: mipi device for corresponding csi channel pads
++ * @mipi: mipi device for corresponding csi channel pads, or NULL if not applicable (TPG, error)
+ * @pixel_rate: active pixel rate from the sensor on this channel
+ */
+ struct tegra_csi_channel {
--- /dev/null
+From c4d344163c3a7f90712525f931a6c016bbb35e18 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Wed, 2 Nov 2022 12:01:02 +0100
+Subject: staging: media: tegra-video: fix device_node use after free
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit c4d344163c3a7f90712525f931a6c016bbb35e18 upstream.
+
+At probe time this code path is followed:
+
+ * tegra_csi_init
+ * tegra_csi_channels_alloc
+ * for_each_child_of_node(node, channel) -- iterates over channels
+ * automatically gets 'channel'
+ * tegra_csi_channel_alloc()
+ * saves into chan->of_node a pointer to the channel OF node
+ * automatically gets and puts 'channel'
+ * now the node saved in chan->of_node has refcount 0, can disappear
+ * tegra_csi_channels_init
+ * iterates over channels
+ * tegra_csi_channel_init -- uses chan->of_node
+
+After that, chan->of_node keeps storing the node until the device is
+removed.
+
+of_node_get() the node and of_node_put() it during teardown to avoid any
+risk.
+
+Fixes: 1ebaeb09830f ("media: tegra-video: Add support for external sensor capture")
+Cc: stable@vger.kernel.org
+Cc: Sowjanya Komatineni <skomatineni@nvidia.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/media/tegra-video/csi.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/media/tegra-video/csi.c
++++ b/drivers/staging/media/tegra-video/csi.c
+@@ -433,7 +433,7 @@ static int tegra_csi_channel_alloc(struc
+ for (i = 0; i < chan->numgangports; i++)
+ chan->csi_port_nums[i] = port_num + i * CSI_PORTS_PER_BRICK;
+
+- chan->of_node = node;
++ chan->of_node = of_node_get(node);
+ chan->numpads = num_pads;
+ if (num_pads & 0x2) {
+ chan->pads[0].flags = MEDIA_PAD_FL_SINK;
+@@ -641,6 +641,7 @@ static void tegra_csi_channels_cleanup(s
+ media_entity_cleanup(&subdev->entity);
+ }
+
++ of_node_put(chan->of_node);
+ list_del(&chan->list);
+ kfree(chan);
+ }
--- /dev/null
+From e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Tue, 6 Dec 2022 23:18:01 +0900
+Subject: tracing: Fix complicated dependency of CONFIG_TRACER_MAX_TRACE
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f upstream.
+
+Both CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER partially enables the
+CONFIG_TRACER_MAX_TRACE code, but that is complicated and has
+introduced a bug; It declares tracing_max_lat_fops data structure outside
+of #ifdefs, but since it is defined only when CONFIG_TRACER_MAX_TRACE=y
+or CONFIG_HWLAT_TRACER=y, if only CONFIG_OSNOISE_TRACER=y, that
+declaration comes to a definition(!).
+
+To fix this issue, and do not repeat the similar problem, makes
+CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER enables the
+CONFIG_TRACER_MAX_TRACE always. It has there benefits;
+- Fix the tracing_max_lat_fops bug
+- Simplify the #ifdefs
+- CONFIG_TRACER_MAX_TRACE code is fully enabled, or not.
+
+Link: https://lore.kernel.org/linux-trace-kernel/167033628155.4111793.12185405690820208159.stgit@devnote3
+
+Fixes: 424b650f35c7 ("tracing: Fix missing osnoise tracer on max_latency")
+Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
+Cc: stable@vger.kernel.org
+Reported-by: David Howells <dhowells@redhat.com>
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Link: https://lore.kernel.org/all/166992525941.1716618.13740663757583361463.stgit@warthog.procyon.org.uk/ (original thread and v1)
+Link: https://lore.kernel.org/all/202212052253.VuhZ2ulJ-lkp@intel.com/T/#u (v1 error report)
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/Kconfig | 2 ++
+ kernel/trace/trace.c | 23 +++++++++++++----------
+ kernel/trace/trace.h | 8 +++-----
+ 3 files changed, 18 insertions(+), 15 deletions(-)
+
+--- a/kernel/trace/Kconfig
++++ b/kernel/trace/Kconfig
+@@ -369,6 +369,7 @@ config SCHED_TRACER
+ config HWLAT_TRACER
+ bool "Tracer to detect hardware latencies (like SMIs)"
+ select GENERIC_TRACER
++ select TRACER_MAX_TRACE
+ help
+ This tracer, when enabled will create one or more kernel threads,
+ depending on what the cpumask file is set to, which each thread
+@@ -404,6 +405,7 @@ config HWLAT_TRACER
+ config OSNOISE_TRACER
+ bool "OS Noise tracer"
+ select GENERIC_TRACER
++ select TRACER_MAX_TRACE
+ help
+ In the context of high-performance computing (HPC), the Operating
+ System Noise (osnoise) refers to the interference experienced by an
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -1421,6 +1421,7 @@ int tracing_snapshot_cond_disable(struct
+ return false;
+ }
+ EXPORT_SYMBOL_GPL(tracing_snapshot_cond_disable);
++#define free_snapshot(tr) do { } while (0)
+ #endif /* CONFIG_TRACER_SNAPSHOT */
+
+ void tracer_tracing_off(struct trace_array *tr)
+@@ -1692,6 +1693,8 @@ static ssize_t trace_seq_to_buffer(struc
+ }
+
+ unsigned long __read_mostly tracing_thresh;
++
++#ifdef CONFIG_TRACER_MAX_TRACE
+ static const struct file_operations tracing_max_lat_fops;
+
+ #ifdef LATENCY_FS_NOTIFY
+@@ -1748,18 +1751,14 @@ void latency_fsnotify(struct trace_array
+ irq_work_queue(&tr->fsnotify_irqwork);
+ }
+
+-#elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)
++#else /* !LATENCY_FS_NOTIFY */
+
+ #define trace_create_maxlat_file(tr, d_tracer) \
+ trace_create_file("tracing_max_latency", TRACE_MODE_WRITE, \
+ d_tracer, &tr->max_latency, &tracing_max_lat_fops)
+
+-#else
+-#define trace_create_maxlat_file(tr, d_tracer) do { } while (0)
+ #endif
+
+-#ifdef CONFIG_TRACER_MAX_TRACE
+ /*
+ * Copy the new maximum trace into the separate maximum-trace
+ * structure. (this way the maximum trace is permanently saved,
+@@ -1834,14 +1833,15 @@ update_max_tr(struct trace_array *tr, st
+ ring_buffer_record_off(tr->max_buffer.buffer);
+
+ #ifdef CONFIG_TRACER_SNAPSHOT
+- if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data))
+- goto out_unlock;
++ if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data)) {
++ arch_spin_unlock(&tr->max_lock);
++ return;
++ }
+ #endif
+ swap(tr->array_buffer.buffer, tr->max_buffer.buffer);
+
+ __update_max_tr(tr, tsk, cpu);
+
+- out_unlock:
+ arch_spin_unlock(&tr->max_lock);
+ }
+
+@@ -1888,6 +1888,7 @@ update_max_tr_single(struct trace_array
+ __update_max_tr(tr, tsk, cpu);
+ arch_spin_unlock(&tr->max_lock);
+ }
++
+ #endif /* CONFIG_TRACER_MAX_TRACE */
+
+ static int wait_on_pipe(struct trace_iterator *iter, int full)
+@@ -6563,7 +6564,7 @@ out:
+ return ret;
+ }
+
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+
+ static ssize_t
+ tracing_max_lat_read(struct file *filp, char __user *ubuf,
+@@ -7578,7 +7579,7 @@ static const struct file_operations trac
+ .llseek = generic_file_llseek,
+ };
+
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+ static const struct file_operations tracing_max_lat_fops = {
+ .open = tracing_open_generic,
+ .read = tracing_max_lat_read,
+@@ -9592,7 +9593,9 @@ init_tracer_tracefs(struct trace_array *
+
+ create_trace_options_dir(tr);
+
++#ifdef CONFIG_TRACER_MAX_TRACE
+ trace_create_maxlat_file(tr, d_tracer);
++#endif
+
+ if (ftrace_create_function_files(tr, d_tracer))
+ MEM_FAIL(1, "Could not allocate function filter files");
+--- a/kernel/trace/trace.h
++++ b/kernel/trace/trace.h
+@@ -308,8 +308,7 @@ struct trace_array {
+ struct array_buffer max_buffer;
+ bool allocated_snapshot;
+ #endif
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+ unsigned long max_latency;
+ #ifdef CONFIG_FSNOTIFY
+ struct dentry *d_max_latency;
+@@ -687,12 +686,11 @@ void update_max_tr(struct trace_array *t
+ void *cond_data);
+ void update_max_tr_single(struct trace_array *tr,
+ struct task_struct *tsk, int cpu);
+-#endif /* CONFIG_TRACER_MAX_TRACE */
+
+-#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)) && defined(CONFIG_FSNOTIFY)
++#ifdef CONFIG_FSNOTIFY
+ #define LATENCY_FS_NOTIFY
+ #endif
++#endif /* CONFIG_TRACER_MAX_TRACE */
+
+ #ifdef LATENCY_FS_NOTIFY
+ void latency_fsnotify(struct trace_array *tr);
--- /dev/null
+From c1ac03af6ed45d05786c219d102f37eb44880f28 Mon Sep 17 00:00:00 2001
+From: Yang Jihong <yangjihong1@huawei.com>
+Date: Tue, 29 Nov 2022 19:30:09 +0800
+Subject: tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
+
+From: Yang Jihong <yangjihong1@huawei.com>
+
+commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream.
+
+print_trace_line may overflow seq_file buffer. If the event is not
+consumed, the while loop keeps peeking this event, causing a infinite loop.
+
+Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 088b1e427dbba ("ftrace: pipe fixes")
+Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6788,7 +6788,20 @@ waitagain:
+
+ ret = print_trace_line(iter);
+ if (ret == TRACE_TYPE_PARTIAL_LINE) {
+- /* don't print partial lines */
++ /*
++ * If one print_trace_line() fills entire trace_seq in one shot,
++ * trace_seq_to_user() will returns -EBUSY because save_len == 0,
++ * In this case, we need to consume it, otherwise, loop will peek
++ * this event next time, resulting in an infinite loop.
++ */
++ if (save_len == 0) {
++ iter->seq.full = 0;
++ trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n");
++ trace_consume(iter);
++ break;
++ }
++
++ /* In other cases, don't print partial lines */
+ iter->seq.seq.len = save_len;
+ break;
+ }
--- /dev/null
+From ff4837f7fe59ff018eca4705a70eca5e0b486b97 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Wed, 7 Dec 2022 17:15:57 +0800
+Subject: tracing: Fix issue of missing one synthetic field
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit ff4837f7fe59ff018eca4705a70eca5e0b486b97 upstream.
+
+The maximum number of synthetic fields supported is defined as
+SYNTH_FIELDS_MAX which value currently is 64, but it actually fails
+when try to generate a synthetic event with 64 fields by executing like:
+
+ # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
+ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
+ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
+ int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
+ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
+ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
+ int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
+ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
+ int v63; int v64" >> /sys/kernel/tracing/synthetic_events
+
+Correct the field counting to fix it.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221207091557.3137904-1-zhengyejian1@huawei.com
+
+Cc: <mhiramat@kernel.org>
+Cc: <zanussi@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: c9e759b1e845 ("tracing: Rework synthetic event command parsing")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_synth.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_events_synth.c
++++ b/kernel/trace/trace_events_synth.c
+@@ -1282,12 +1282,12 @@ static int __create_synth_event(const ch
+ goto err_free_arg;
+ }
+
+- fields[n_fields++] = field;
+ if (n_fields == SYNTH_FIELDS_MAX) {
+ synth_err(SYNTH_ERR_TOO_MANY_FIELDS, 0);
+ ret = -EINVAL;
+ goto err_free_arg;
+ }
++ fields[n_fields++] = field;
+
+ n_fields_this_loop++;
+ }
--- /dev/null
+From d5f30a7da8ea8e6450250275cec5670cee3c4264 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Thu, 17 Nov 2022 21:42:49 -0500
+Subject: tracing: Fix race where eprobes can be called before the event
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit d5f30a7da8ea8e6450250275cec5670cee3c4264 upstream.
+
+The flag that tells the event to call its triggers after reading the event
+is set for eprobes after the eprobe is enabled. This leads to a race where
+the eprobe may be triggered at the beginning of the event where the record
+information is NULL. The eprobe then dereferences the NULL record causing
+a NULL kernel pointer bug.
+
+Test for a NULL record to keep this from happening.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221116192552.1066630-1-rafaelmendsr@gmail.com/
+Link: https://lore.kernel.org/all/20221117214249.2addbe10@gandalf.local.home/
+
+Cc: stable@vger.kernel.org
+Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events")
+Reported-by: Rafael Mendonca <rafaelmendsr@gmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_eprobe.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/trace_eprobe.c
++++ b/kernel/trace/trace_eprobe.c
+@@ -563,6 +563,9 @@ static void eprobe_trigger_func(struct e
+ if (unlikely(!rec))
+ return;
+
++ if (unlikely(!rec))
++ return;
++
+ __eprobe_trace_func(edata, rec);
+ }
+
--- /dev/null
+From 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Wed, 7 Dec 2022 11:46:35 +0800
+Subject: tracing/hist: Fix wrong return value in parse_action_params()
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 upstream.
+
+When number of synth fields is more than SYNTH_FIELDS_MAX,
+parse_action_params() should return -EINVAL.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221207034635.2253990-1-zhengyejian1@huawei.com
+
+Cc: <mhiramat@kernel.org>
+Cc: <zanussi@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_hist.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -3564,6 +3564,7 @@ static int parse_action_params(struct tr
+ while (params) {
+ if (data->n_params >= SYNTH_FIELDS_MAX) {
+ hist_err(tr, HIST_ERR_TOO_MANY_PARAMS, 0);
++ ret = -EINVAL;
+ goto out;
+ }
+
--- /dev/null
+From 575b76cb885532aae13a9d979fd476bb2b156cb9 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Tue, 22 Nov 2022 12:23:45 -0500
+Subject: tracing/probes: Handle system names with hyphens
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 575b76cb885532aae13a9d979fd476bb2b156cb9 upstream.
+
+When creating probe names, a check is done to make sure it matches basic C
+standard variable naming standards. Basically, starts with alphabetic or
+underline, and then the rest of the characters have alpha-numeric or
+underline in them.
+
+But system names do not have any true naming conventions, as they are
+created by the TRACE_SYSTEM macro and nothing tests to see what they are.
+The "xhci-hcd" trace events has a '-' in the system name. When trying to
+attach a eprobe to one of these trace points, it fails because the system
+name does not follow the variable naming convention because of the
+hyphen, and the eprobe checks fail on this.
+
+Allow hyphens in the system name so that eprobes can attach to the
+"xhci-hcd" trace events.
+
+Link: https://lore.kernel.org/all/Y3eJ8GiGnEvVd8%2FN@macondo/
+Link: https://lore.kernel.org/linux-trace-kernel/20221122122345.160f5077@gandalf.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 5b7a96220900e ("tracing/probe: Check event/group naming rule at parsing")
+Reported-by: Rafael Mendonca <rafaelmendsr@gmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.h | 19 ++++++++++++++++---
+ kernel/trace/trace_probe.c | 2 +-
+ 2 files changed, 17 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace.h
++++ b/kernel/trace/trace.h
+@@ -1966,17 +1966,30 @@ static __always_inline void trace_iterat
+ }
+
+ /* Check the name is good for event/group/fields */
+-static inline bool is_good_name(const char *name)
++static inline bool __is_good_name(const char *name, bool hash_ok)
+ {
+- if (!isalpha(*name) && *name != '_')
++ if (!isalpha(*name) && *name != '_' && (!hash_ok || *name != '-'))
+ return false;
+ while (*++name != '\0') {
+- if (!isalpha(*name) && !isdigit(*name) && *name != '_')
++ if (!isalpha(*name) && !isdigit(*name) && *name != '_' &&
++ (!hash_ok || *name != '-'))
+ return false;
+ }
+ return true;
+ }
+
++/* Check the name is good for event/group/fields */
++static inline bool is_good_name(const char *name)
++{
++ return __is_good_name(name, false);
++}
++
++/* Check the name is good for system */
++static inline bool is_good_system_name(const char *name)
++{
++ return __is_good_name(name, true);
++}
++
+ /* Convert certain expected symbols into '_' when generating event names */
+ static inline void sanitize_event_name(char *name)
+ {
+--- a/kernel/trace/trace_probe.c
++++ b/kernel/trace/trace_probe.c
+@@ -246,7 +246,7 @@ int traceprobe_parse_event_name(const ch
+ return -EINVAL;
+ }
+ strlcpy(buf, event, slash - event + 1);
+- if (!is_good_name(buf)) {
++ if (!is_good_system_name(buf)) {
+ trace_probe_log_err(offset, BAD_GROUP_NAME);
+ return -EINVAL;
+ }
--- /dev/null
+From 1993bf97992df2d560287f3c4120eda57426843d Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 19 Dec 2022 23:35:10 +0900
+Subject: x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 1993bf97992df2d560287f3c4120eda57426843d upstream.
+
+Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping
+speculative execution after RET instruction, kprobes always failes to
+check the probed instruction boundary by decoding the function body if
+the probed address is after such sequence. (Note that some conditional
+code blocks will be placed after function return, if compiler decides
+it is not on the hot path.)
+
+This is because kprobes expects kgdb puts the INT3 as a software
+breakpoint and it will replace the original instruction.
+But these INT3 are not such purpose, it doesn't need to recover the
+original instruction.
+
+To avoid this issue, kprobes checks whether the INT3 is owned by
+kgdb or not, and if so, stop decoding and make it fail. The other
+INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be
+treated as a one-byte instruction.
+
+Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation")
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/167146051026.1374301.392728975473572291.stgit@devnote3
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -37,6 +37,7 @@
+ #include <linux/extable.h>
+ #include <linux/kdebug.h>
+ #include <linux/kallsyms.h>
++#include <linux/kgdb.h>
+ #include <linux/ftrace.h>
+ #include <linux/kasan.h>
+ #include <linux/moduleloader.h>
+@@ -283,12 +284,15 @@ static int can_probe(unsigned long paddr
+ if (ret < 0)
+ return 0;
+
++#ifdef CONFIG_KGDB
+ /*
+- * Another debugging subsystem might insert this breakpoint.
+- * In that case, we can't recover it.
++ * If there is a dynamically installed kgdb sw breakpoint,
++ * this function should not be probed.
+ */
+- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE &&
++ kgdb_has_hit_break(addr))
+ return 0;
++#endif
+ addr += insn.length;
+ }
+
--- /dev/null
+From 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 19 Dec 2022 23:35:19 +0900
+Subject: x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 upstream.
+
+Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping
+speculative execution after function return, kprobe jump optimization
+always fails on the functions with such INT3 inside the function body.
+(It already checks the INT3 padding between functions, but not inside
+ the function)
+
+To avoid this issue, as same as kprobes, check whether the INT3 comes
+from kgdb or not, and if so, stop decoding and make it fail. The other
+INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be
+treated as a one-byte instruction.
+
+Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation")
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/167146051929.1374301.7419382929328081706.stgit@devnote3
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/opt.c | 28 ++++++++--------------------
+ 1 file changed, 8 insertions(+), 20 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/opt.c
++++ b/arch/x86/kernel/kprobes/opt.c
+@@ -15,6 +15,7 @@
+ #include <linux/extable.h>
+ #include <linux/kdebug.h>
+ #include <linux/kallsyms.h>
++#include <linux/kgdb.h>
+ #include <linux/ftrace.h>
+ #include <linux/objtool.h>
+ #include <linux/pgtable.h>
+@@ -279,19 +280,6 @@ static int insn_is_indirect_jump(struct
+ return ret;
+ }
+
+-static bool is_padding_int3(unsigned long addr, unsigned long eaddr)
+-{
+- unsigned char ops;
+-
+- for (; addr < eaddr; addr++) {
+- if (get_kernel_nofault(ops, (void *)addr) < 0 ||
+- ops != INT3_INSN_OPCODE)
+- return false;
+- }
+-
+- return true;
+-}
+-
+ /* Decode whole function to ensure any instructions don't jump into target */
+ static int can_optimize(unsigned long paddr)
+ {
+@@ -334,15 +322,15 @@ static int can_optimize(unsigned long pa
+ ret = insn_decode_kernel(&insn, (void *)recovered_insn);
+ if (ret < 0)
+ return 0;
+-
++#ifdef CONFIG_KGDB
+ /*
+- * In the case of detecting unknown breakpoint, this could be
+- * a padding INT3 between functions. Let's check that all the
+- * rest of the bytes are also INT3.
++ * If there is a dynamically installed kgdb sw breakpoint,
++ * this function should not be probed.
+ */
+- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
+- return is_padding_int3(addr, paddr - offset + size) ? 1 : 0;
+-
++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE &&
++ kgdb_has_hit_break(addr))
++ return 0;
++#endif
+ /* Recover address */
+ insn.kaddr = (void *)addr;
+ insn.next_byte = (void *)(addr + insn.length);
--- /dev/null
+From be1b670f61443aa5d0d01782e9b8ea0ee825d018 Mon Sep 17 00:00:00 2001
+From: Ashok Raj <ashok.raj@intel.com>
+Date: Tue, 29 Nov 2022 13:08:27 -0800
+Subject: x86/microcode/intel: Do not retry microcode reloading on the APs
+
+From: Ashok Raj <ashok.raj@intel.com>
+
+commit be1b670f61443aa5d0d01782e9b8ea0ee825d018 upstream.
+
+The retries in load_ucode_intel_ap() were in place to support systems
+with mixed steppings. Mixed steppings are no longer supported and there is
+only one microcode image at a time. Any retries will simply reattempt to
+apply the same image over and over without making progress.
+
+ [ bp: Zap the circumstantial reasoning from the commit message. ]
+
+Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
+Signed-off-by: Ashok Raj <ashok.raj@intel.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -621,7 +621,6 @@ void load_ucode_intel_ap(void)
+ else
+ iup = &intel_ucode_patch;
+
+-reget:
+ if (!*iup) {
+ patch = __load_ucode_intel(&uci);
+ if (!patch)
+@@ -632,12 +631,7 @@ reget:
+
+ uci.mc = *iup;
+
+- if (apply_microcode_early(&uci, true)) {
+- /* Mixed-silicon system? Try to refetch the proper patch: */
+- *iup = NULL;
+-
+- goto reget;
+- }
++ apply_microcode_early(&uci, true);
+ }
+
+ static struct microcode_intel *find_patch(struct ucode_cpu_info *uci)
projects / thirdparty / kernel / stable-queue.git / commitdiff
