--- /dev/null
+From stable+bounces-78114-greg=kroah.com@vger.kernel.org Fri Sep 27 15:48:44 2024
+From: Pu Lehui <pulehui@huaweicloud.com>
+Date: Fri, 27 Sep 2024 13:51:18 +0000
+Subject: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
+To: stable@vger.kernel.org, bpf@vger.kernel.org
+Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Sasha Levin" <sashal@kernel.org>, "Toke Høiland-Jørgensen" <toke@redhat.com>, "Pu Lehui" <pulehui@huawei.com>
+Message-ID: <20240927135118.1432057-4-pulehui@huaweicloud.com>
+
+From: Toke Høiland-Jørgensen <toke@redhat.com>
+
+[ Upstream commit 281d464a34f540de166cee74b723e97ac2515ec3 ]
+
+The devmap code allocates a number hash buckets equal to the next power
+of two of the max_entries value provided when creating the map. When
+rounding up to the next power of two, the 32-bit variable storing the
+number of buckets can overflow, and the code checks for overflow by
+checking if the truncated 32-bit value is equal to 0. However, on 32-bit
+arches the rounding up itself can overflow mid-way through, because it
+ends up doing a left-shift of 32 bits on an unsigned long value. If the
+size of an unsigned long is four bytes, this is undefined behaviour, so
+there is no guarantee that we'll end up with a nice and tidy 0-value at
+the end.
+
+Syzbot managed to turn this into a crash on arm32 by creating a
+DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
+Fix this by moving the overflow check to before the rounding up
+operation.
+
+Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
+Link: https://lore.kernel.org/r/000000000000ed666a0611af6818@google.com
+Reported-and-tested-by: syzbot+8cd36f6b65f3cafd400a@syzkaller.appspotmail.com
+Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
+Message-ID: <20240307120340.99577-2-toke@redhat.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Pu Lehui <pulehui@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/bpf/devmap.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/kernel/bpf/devmap.c
++++ b/kernel/bpf/devmap.c
+@@ -131,10 +131,13 @@ static int dev_map_init_map(struct bpf_d
+ bpf_map_init_from_attr(&dtab->map, attr);
+
+ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
+- dtab->n_buckets = roundup_pow_of_two(dtab->map.max_entries);
+-
+- if (!dtab->n_buckets) /* Overflow check */
++ /* hash table size must be power of 2; roundup_pow_of_two() can
++ * overflow into UB on 32-bit arches, so check that first
++ */
++ if (dtab->map.max_entries > 1UL << 31)
+ return -EINVAL;
++
++ dtab->n_buckets = roundup_pow_of_two(dtab->map.max_entries);
+ cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;
+ } else {
+ cost += (u64) dtab->map.max_entries * sizeof(struct bpf_dtab_netdev *);
--- /dev/null
+From d176708ffc20332d1c730098d2b111e0b77ece82 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 28 Feb 2022 22:52:31 -0800
+Subject: Input: goodix - use the new soc_intel_is_byt() helper
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit d176708ffc20332d1c730098d2b111e0b77ece82 upstream.
+
+Use the new soc_intel_is_byt() helper from linux/platform_data/x86/soc.h.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20220131143539.109142-5-hdegoede@redhat.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+[Ricardo: Resolved minor cherry-pick conflict. The file linux/regulator/
+ consumer.h is not #included in the upstream version but it is in
+ v5.10.y. ]
+Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/touchscreen/goodix.c | 18 ++----------------
+ 1 file changed, 2 insertions(+), 16 deletions(-)
+
+--- a/drivers/input/touchscreen/goodix.c
++++ b/drivers/input/touchscreen/goodix.c
+@@ -23,6 +23,7 @@
+ #include <linux/delay.h>
+ #include <linux/irq.h>
+ #include <linux/interrupt.h>
++#include <linux/platform_data/x86/soc.h>
+ #include <linux/regulator/consumer.h>
+ #include <linux/slab.h>
+ #include <linux/acpi.h>
+@@ -718,21 +719,6 @@ static int goodix_reset(struct goodix_ts
+ }
+
+ #ifdef ACPI_GPIO_SUPPORT
+-#include <asm/cpu_device_id.h>
+-#include <asm/intel-family.h>
+-
+-static const struct x86_cpu_id baytrail_cpu_ids[] = {
+- { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT, X86_FEATURE_ANY, },
+- {}
+-};
+-
+-static inline bool is_byt(void)
+-{
+- const struct x86_cpu_id *id = x86_match_cpu(baytrail_cpu_ids);
+-
+- return !!id;
+-}
+-
+ static const struct acpi_gpio_params first_gpio = { 0, 0, false };
+ static const struct acpi_gpio_params second_gpio = { 1, 0, false };
+
+@@ -816,7 +802,7 @@ static int goodix_add_acpi_gpio_mappings
+ dev_info(dev, "Using ACPI INTI and INTO methods for IRQ pin access\n");
+ ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_METHOD;
+ gpio_mapping = acpi_goodix_reset_only_gpios;
+- } else if (is_byt() && ts->gpio_count == 2 && ts->gpio_int_idx == -1) {
++ } else if (soc_intel_is_byt() && ts->gpio_count == 2 && ts->gpio_int_idx == -1) {
+ dev_info(dev, "No ACPI GpioInt resource, assuming that the GPIO order is reset, int\n");
+ ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO;
+ gpio_mapping = acpi_goodix_int_last_gpios;
--- /dev/null
+From matttbe@kernel.org Tue Oct 1 10:14:56 2024
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Mon, 30 Sep 2024 18:23:46 +0200
+Subject: mptcp: fix sometimes-uninitialized warning
+To: stable@vger.kernel.org, gregkh@linuxfoundation.org
+Cc: MPTCP Upstream <mptcp@lists.linux.dev>, "Matthieu Baerts (NGI0)" <matttbe@kernel.org>, Nathan Chancellor <nathan@kernel.org>
+Message-ID: <20240930162345.3938790-2-matttbe@kernel.org>
+
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+
+Nathan reported this issue:
+
+ $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 LLVM_IAS=1 mrproper allmodconfig net/mptcp/subflow.o
+ net/mptcp/subflow.c:877:6: warning: variable 'incr' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
+ 877 | if (WARN_ON_ONCE(offset > skb->len))
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ include/asm-generic/bug.h:101:33: note: expanded from macro 'WARN_ON_ONCE'
+ 101 | #define WARN_ON_ONCE(condition) ({ \
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 102 | int __ret_warn_on = !!(condition); \
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 103 | if (unlikely(__ret_warn_on)) \
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 104 | __WARN_FLAGS(BUGFLAG_ONCE | \
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 105 | BUGFLAG_TAINT(TAINT_WARN)); \
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 106 | unlikely(__ret_warn_on); \
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 107 | })
+ | ~~
+ net/mptcp/subflow.c:893:6: note: uninitialized use occurs here
+ 893 | if (incr)
+ | ^~~~
+ net/mptcp/subflow.c:877:2: note: remove the 'if' if its condition is always false
+ 877 | if (WARN_ON_ONCE(offset > skb->len))
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 878 | goto out;
+ | ~~~~~~~~
+ net/mptcp/subflow.c:874:18: note: initialize the variable 'incr' to silence this warning
+ 874 | u32 offset, incr, avail_len;
+ | ^
+ | = 0
+ 1 warning generated.
+
+As mentioned by Nathan, this issue is present because 5.10 does not
+include commit ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling"),
+which removed the use of 'incr' in the error path added by this change.
+This other commit does not really look suitable for stable, hence this
+dedicated patch for 5.10.
+
+Fixes: e93fa44f0714 ("mptcp: fix duplicate data handling")
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Closes: https://lore.kernel.org/20240928175524.GA1713144@thelio-3990X
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -871,7 +871,7 @@ static void mptcp_subflow_discard_data(s
+ struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
+ bool fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
+ struct tcp_sock *tp = tcp_sk(ssk);
+- u32 offset, incr, avail_len;
++ u32 offset, incr = 0, avail_len;
+
+ offset = tp->copied_seq - TCP_SKB_CB(skb)->seq;
+ if (WARN_ON_ONCE(offset > skb->len))
--- /dev/null
+From d05b5e0baf424c8c4b4709ac11f66ab726c8deaf Mon Sep 17 00:00:00 2001
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+Date: Thu, 8 Jun 2023 08:00:06 +0530
+Subject: powercap: RAPL: fix invalid initialization for pl4_supported field
+
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+
+commit d05b5e0baf424c8c4b4709ac11f66ab726c8deaf upstream.
+
+The current initialization of the struct x86_cpu_id via
+pl4_support_ids[] is partial and wrong. It is initializing
+"stepping" field with "X86_FEATURE_ANY" instead of "feature" field.
+
+Use X86_MATCH_INTEL_FAM6_MODEL macro instead of initializing
+each field of the struct x86_cpu_id for pl4_supported list of CPUs.
+This X86_MATCH_INTEL_FAM6_MODEL macro internally uses another macro
+X86_MATCH_VENDOR_FAM_MODEL_FEATURE for X86 based CPU matching with
+appropriate initialized values.
+
+Reported-by: Dave Hansen <dave.hansen@intel.com>
+Link: https://lore.kernel.org/lkml/28ead36b-2d9e-1a36-6f4e-04684e420260@intel.com
+Fixes: eb52bc2ae5b8 ("powercap: RAPL: Add Power Limit4 support for Meteor Lake SoC")
+Fixes: b08b95cf30f5 ("powercap: RAPL: Add Power Limit4 support for Alder Lake-N and Raptor Lake-P")
+Fixes: 515755906921 ("powercap: RAPL: Add Power Limit4 support for RaptorLake")
+Fixes: 1cc5b9a411e4 ("powercap: Add Power Limit4 support for Alder Lake SoC")
+Fixes: 8365a898fe53 ("powercap: Add Power Limit4 support")
+Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+[ Ricardo: I only kept TIGERLAKE in pl4_support_ids as only this model is
+ enumerated before this changeset. ]
+Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/powercap/intel_rapl_msr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/powercap/intel_rapl_msr.c
++++ b/drivers/powercap/intel_rapl_msr.c
+@@ -126,7 +126,7 @@ static int rapl_msr_write_raw(int cpu, s
+
+ /* List of verified CPUs. */
+ static const struct x86_cpu_id pl4_support_ids[] = {
+- { X86_VENDOR_INTEL, 6, INTEL_FAM6_TIGERLAKE_L, X86_FEATURE_ANY },
++ X86_MATCH_INTEL_FAM6_MODEL(TIGERLAKE_L, NULL),
+ {}
+ };
+
--- /dev/null
+From stable+bounces-78113-greg=kroah.com@vger.kernel.org Fri Sep 27 15:48:38 2024
+From: Pu Lehui <pulehui@huaweicloud.com>
+Date: Fri, 27 Sep 2024 13:51:17 +0000
+Subject: Revert "bpf: Eliminate rlimit-based memory accounting for devmap maps"
+To: stable@vger.kernel.org, bpf@vger.kernel.org
+Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Sasha Levin" <sashal@kernel.org>, "Toke Høiland-Jørgensen" <toke@redhat.com>, "Pu Lehui" <pulehui@huawei.com>
+Message-ID: <20240927135118.1432057-3-pulehui@huaweicloud.com>
+
+From: Pu Lehui <pulehui@huawei.com>
+
+This reverts commit 70294d8bc31f3b7789e5e32f757aa9344556d964 which is
+commit 844f157f6c0a905d039d2e20212ab3231f2e5eaf upstream.
+
+Commit 70294d8bc31f ("bpf: Eliminate rlimit-based memory accounting for
+devmap maps") is part of the v5.11+ base mechanism of memcg-based memory
+accounting[0]. The commit cannot be independently backported to the 5.10
+stable branch, otherwise the related memory when creating devmap will be
+unrestricted. Let's roll back to rlimit-based memory accounting mode for
+devmap.
+
+Link: https://lore.kernel.org/bpf/20201201215900.3569844-1-guro@fb.com [0]
+Signed-off-by: Pu Lehui <pulehui@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/bpf/devmap.c | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+--- a/kernel/bpf/devmap.c
++++ b/kernel/bpf/devmap.c
+@@ -109,6 +109,8 @@ static inline struct hlist_head *dev_map
+ static int dev_map_init_map(struct bpf_dtab *dtab, union bpf_attr *attr)
+ {
+ u32 valsize = attr->value_size;
++ u64 cost = 0;
++ int err;
+
+ /* check sanity of attributes. 2 value sizes supported:
+ * 4 bytes: ifindex
+@@ -133,13 +135,21 @@ static int dev_map_init_map(struct bpf_d
+
+ if (!dtab->n_buckets) /* Overflow check */
+ return -EINVAL;
++ cost += (u64) sizeof(struct hlist_head) * dtab->n_buckets;
++ } else {
++ cost += (u64) dtab->map.max_entries * sizeof(struct bpf_dtab_netdev *);
+ }
+
++ /* if map size is larger than memlock limit, reject it */
++ err = bpf_map_charge_init(&dtab->map.memory, cost);
++ if (err)
++ return -EINVAL;
++
+ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
+ dtab->dev_index_head = dev_map_create_hash(dtab->n_buckets,
+ dtab->map.numa_node);
+ if (!dtab->dev_index_head)
+- return -ENOMEM;
++ goto free_charge;
+
+ spin_lock_init(&dtab->index_lock);
+ } else {
+@@ -147,10 +157,14 @@ static int dev_map_init_map(struct bpf_d
+ sizeof(struct bpf_dtab_netdev *),
+ dtab->map.numa_node);
+ if (!dtab->netdev_map)
+- return -ENOMEM;
++ goto free_charge;
+ }
+
+ return 0;
++
++free_charge:
++ bpf_map_charge_finish(&dtab->map.memory);
++ return -ENOMEM;
+ }
+
+ static struct bpf_map *dev_map_alloc(union bpf_attr *attr)
--- /dev/null
+From stable+bounces-78115-greg=kroah.com@vger.kernel.org Fri Sep 27 15:48:43 2024
+From: Pu Lehui <pulehui@huaweicloud.com>
+Date: Fri, 27 Sep 2024 13:51:16 +0000
+Subject: Revert "bpf: Fix DEVMAP_HASH overflow check on 32-bit arches"
+To: stable@vger.kernel.org, bpf@vger.kernel.org
+Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Sasha Levin" <sashal@kernel.org>, "Toke Høiland-Jørgensen" <toke@redhat.com>, "Pu Lehui" <pulehui@huawei.com>
+Message-ID: <20240927135118.1432057-2-pulehui@huaweicloud.com>
+
+From: Pu Lehui <pulehui@huawei.com>
+
+This reverts commit 225da02acdc97af01b6bc6ce1a3e5362bf01d3fb which is
+commit 281d464a34f540de166cee74b723e97ac2515ec3 upstream.
+
+Commit 225da02acdc9 ("bpf: fix DEVMAP_HASH overflow check on 32-bit
+architectures") relies on the v5.11+ base mechanism of memcg-based
+memory accounting[0], which is not yet supported on the 5.10 stable
+branch, so let's revert this commit in preparation for re-adapting it.
+
+Link: https://lore.kernel.org/bpf/20201201215900.3569844-1-guro@fb.com [0]
+Signed-off-by: Pu Lehui <pulehui@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/bpf/devmap.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/kernel/bpf/devmap.c
++++ b/kernel/bpf/devmap.c
+@@ -129,14 +129,13 @@ static int dev_map_init_map(struct bpf_d
+ bpf_map_init_from_attr(&dtab->map, attr);
+
+ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
+- /* hash table size must be power of 2; roundup_pow_of_two() can
+- * overflow into UB on 32-bit arches, so check that first
+- */
+- if (dtab->map.max_entries > 1UL << 31)
+- return -EINVAL;
+-
+ dtab->n_buckets = roundup_pow_of_two(dtab->map.max_entries);
+
++ if (!dtab->n_buckets) /* Overflow check */
++ return -EINVAL;
++ }
++
++ if (attr->map_type == BPF_MAP_TYPE_DEVMAP_HASH) {
+ dtab->dev_index_head = dev_map_create_hash(dtab->n_buckets,
+ dtab->map.numa_node);
+ if (!dtab->dev_index_head)
--- /dev/null
+From 76a0e79bc84f466999fa501fce5bf7a07641b8a7 Mon Sep 17 00:00:00 2001
+From: Scott Mayhew <smayhew@redhat.com>
+Date: Wed, 28 Aug 2024 15:51:29 -0400
+Subject: selinux,smack: don't bypass permissions check in inode_setsecctx hook
+
+From: Scott Mayhew <smayhew@redhat.com>
+
+commit 76a0e79bc84f466999fa501fce5bf7a07641b8a7 upstream.
+
+Marek Gresko reports that the root user on an NFS client is able to
+change the security labels on files on an NFS filesystem that is
+exported with root squashing enabled.
+
+The end of the kerneldoc comment for __vfs_setxattr_noperm() states:
+
+ * This function requires the caller to lock the inode's i_mutex before it
+ * is executed. It also assumes that the caller will make the appropriate
+ * permission checks.
+
+nfsd_setattr() does do permissions checking via fh_verify() and
+nfsd_permission(), but those don't do all the same permissions checks
+that are done by security_inode_setxattr() and its related LSM hooks do.
+
+Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),
+simplest solution appears to be to replace the call to
+__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This
+fixes the above issue and has the added benefit of causing nfsd to
+recall conflicting delegations on a file when a client tries to change
+its security label.
+
+Cc: stable@kernel.org
+Reported-by: Marek Gresko <marek.gresko@protonmail.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=218809
+Signed-off-by: Scott Mayhew <smayhew@redhat.com>
+Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
+Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
+Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Acked-by: Casey Schaufler <casey@schaufler-ca.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+[Shivani: Modified to apply on v5.10.y]
+Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/selinux/hooks.c | 3 ++-
+ security/smack/smack_lsm.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/security/selinux/hooks.c
++++ b/security/selinux/hooks.c
+@@ -6570,7 +6570,8 @@ static int selinux_inode_notifysecctx(st
+ */
+ static int selinux_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen)
+ {
+- return __vfs_setxattr_noperm(dentry, XATTR_NAME_SELINUX, ctx, ctxlen, 0);
++ return __vfs_setxattr_locked(dentry, XATTR_NAME_SELINUX, ctx, ctxlen, 0,
++ NULL);
+ }
+
+ static int selinux_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen)
+--- a/security/smack/smack_lsm.c
++++ b/security/smack/smack_lsm.c
+@@ -4651,7 +4651,8 @@ static int smack_inode_notifysecctx(stru
+
+ static int smack_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen)
+ {
+- return __vfs_setxattr_noperm(dentry, XATTR_NAME_SMACK, ctx, ctxlen, 0);
++ return __vfs_setxattr_locked(dentry, XATTR_NAME_SMACK, ctx, ctxlen, 0,
++ NULL);
+ }
+
+ static int smack_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen)
xen-introduce-generic-helper-checking-for-memory-map.patch
xen-move-max_pfn-in-xen_memory_setup-out-of-function.patch
xen-add-capability-to-remap-non-ram-pages-to-differe.patch
-xen-tolerate-acpi-nvs-memory-overlapping-with-xen-al.patch
xen-swiotlb-add-alignment-check-for-dma-buffers.patch
tpm-clean-up-tpm-space-after-command-failure.patch
selftests-bpf-fix-compile-error-from-rlim_t-in-sk_st.patch
netfilter-nf_tables-keep-deleted-flowtable-hooks-unt.patch
netfilter-ctnetlink-compile-ctnetlink_label_size-wit.patch
drm-amd-display-fix-synaptics-cascaded-panamera-dsc-determination.patch
+input-goodix-use-the-new-soc_intel_is_byt-helper.patch
+powercap-rapl-fix-invalid-initialization-for-pl4_supported-field.patch
+x86-mm-switch-to-new-intel-cpu-model-defines.patch
+revert-bpf-fix-devmap_hash-overflow-check-on-32-bit-arches.patch
+revert-bpf-eliminate-rlimit-based-memory-accounting-for-devmap-maps.patch
+bpf-fix-devmap_hash-overflow-check-on-32-bit-arches.patch
+selinux-smack-don-t-bypass-permissions-check-in-inode_setsecctx-hook.patch
+mptcp-fix-sometimes-uninitialized-warning.patch
--- /dev/null
+From 2eda374e883ad297bd9fe575a16c1dc850346075 Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+Date: Wed, 24 Apr 2024 11:15:18 -0700
+Subject: x86/mm: Switch to new Intel CPU model defines
+
+From: Tony Luck <tony.luck@intel.com>
+
+commit 2eda374e883ad297bd9fe575a16c1dc850346075 upstream.
+
+New CPU #defines encode vendor and family as well as model.
+
+[ dhansen: vertically align 0's in invlpg_miss_ids[] ]
+
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Link: https://lore.kernel.org/all/20240424181518.41946-1-tony.luck%40intel.com
+[ Ricardo: I used the old match macro X86_MATCH_INTEL_FAM6_MODEL()
+ instead of X86_MATCH_VFM() as in the upstream commit.
+ I also kept the ALDERLAKE_N name instead of ATOM_GRACEMONT. Both refer
+ to the same CPU model. ]
+Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/init.c | 16 ++++++----------
+ 1 file changed, 6 insertions(+), 10 deletions(-)
+
+--- a/arch/x86/mm/init.c
++++ b/arch/x86/mm/init.c
+@@ -257,21 +257,17 @@ static void __init probe_page_size_mask(
+ }
+ }
+
+-#define INTEL_MATCH(_model) { .vendor = X86_VENDOR_INTEL, \
+- .family = 6, \
+- .model = _model, \
+- }
+ /*
+ * INVLPG may not properly flush Global entries
+ * on these CPUs when PCIDs are enabled.
+ */
+ static const struct x86_cpu_id invlpg_miss_ids[] = {
+- INTEL_MATCH(INTEL_FAM6_ALDERLAKE ),
+- INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
+- INTEL_MATCH(INTEL_FAM6_ALDERLAKE_N ),
+- INTEL_MATCH(INTEL_FAM6_RAPTORLAKE ),
+- INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P),
+- INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S),
++ X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE, 0),
++ X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_L, 0),
++ X86_MATCH_INTEL_FAM6_MODEL(ALDERLAKE_N, 0),
++ X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE, 0),
++ X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_P, 0),
++ X86_MATCH_INTEL_FAM6_MODEL(RAPTORLAKE_S, 0),
+ {}
+ };
+
+++ /dev/null
-From 83584927ca9e4b6d4c60f20d53d54f50e793d5e6 Mon Sep 17 00:00:00 2001
-From: Sasha Levin <sashal@kernel.org>
-Date: Fri, 2 Aug 2024 20:14:22 +0200
-Subject: xen: tolerate ACPI NVS memory overlapping with Xen allocated memory
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Juergen Gross <jgross@suse.com>
-
-[ Upstream commit be35d91c8880650404f3bf813573222dfb106935 ]
-
-In order to minimize required special handling for running as Xen PV
-dom0, the memory layout is modified to match that of the host. This
-requires to have only RAM at the locations where Xen allocated memory
-is living. Unfortunately there seem to be some machines, where ACPI
-NVS is located at 64 MB, resulting in a conflict with the loaded
-kernel or the initial page tables built by Xen.
-
-Avoid this conflict by swapping the ACPI NVS area in the memory map
-with unused RAM. This is possible via modification of the dom0 P2M map.
-Accesses to the ACPI NVS area are done either for saving and restoring
-it across suspend operations (this will work the same way as before),
-or by ACPI code when NVS memory is referenced from other ACPI tables.
-The latter case is handled by a Xen specific indirection of
-acpi_os_ioremap().
-
-While the E820 map can (and should) be modified right away, the P2M
-map can be updated only after memory allocation is working, as the P2M
-map might need to be extended.
-
-Fixes: 808fdb71936c ("xen: check for kernel memory conflicting with memory layout")
-Signed-off-by: Juergen Gross <jgross@suse.com>
-Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-Reviewed-by: Jan Beulich <jbeulich@suse.com>
-Signed-off-by: Juergen Gross <jgross@suse.com>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- arch/x86/xen/setup.c | 92 +++++++++++++++++++++++++++++++++++++++++++-
- 1 file changed, 91 insertions(+), 1 deletion(-)
-
-diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
-index ffe2b3918cbb2..5126b5b79383b 100644
---- a/arch/x86/xen/setup.c
-+++ b/arch/x86/xen/setup.c
-@@ -539,6 +539,8 @@ void __init xen_remap_memory(void)
- set_pte_mfn(buf, mfn_save, PAGE_KERNEL);
-
- pr_info("Remapped %ld page(s)\n", remapped);
-+
-+ xen_do_remap_nonram();
- }
-
- static unsigned long __init xen_get_pages_limit(void)
-@@ -669,14 +671,102 @@ phys_addr_t __init xen_find_free_area(phys_addr_t size)
- return 0;
- }
-
-+/*
-+ * Swap a non-RAM E820 map entry with RAM above ini_nr_pages.
-+ * Note that the E820 map is modified accordingly, but the P2M map isn't yet.
-+ * The adaption of the P2M must be deferred until page allocation is possible.
-+ */
-+static void __init xen_e820_swap_entry_with_ram(struct e820_entry *swap_entry)
-+{
-+ struct e820_entry *entry;
-+ unsigned int mapcnt;
-+ phys_addr_t mem_end = PFN_PHYS(ini_nr_pages);
-+ phys_addr_t swap_addr, swap_size, entry_end;
-+
-+ swap_addr = PAGE_ALIGN_DOWN(swap_entry->addr);
-+ swap_size = PAGE_ALIGN(swap_entry->addr - swap_addr + swap_entry->size);
-+ entry = xen_e820_table.entries;
-+
-+ for (mapcnt = 0; mapcnt < xen_e820_table.nr_entries; mapcnt++) {
-+ entry_end = entry->addr + entry->size;
-+ if (entry->type == E820_TYPE_RAM && entry->size >= swap_size &&
-+ entry_end - swap_size >= mem_end) {
-+ /* Reduce RAM entry by needed space (whole pages). */
-+ entry->size -= swap_size;
-+
-+ /* Add new entry at the end of E820 map. */
-+ entry = xen_e820_table.entries +
-+ xen_e820_table.nr_entries;
-+ xen_e820_table.nr_entries++;
-+
-+ /* Fill new entry (keep size and page offset). */
-+ entry->type = swap_entry->type;
-+ entry->addr = entry_end - swap_size +
-+ swap_addr - swap_entry->addr;
-+ entry->size = swap_entry->size;
-+
-+ /* Convert old entry to RAM, align to pages. */
-+ swap_entry->type = E820_TYPE_RAM;
-+ swap_entry->addr = swap_addr;
-+ swap_entry->size = swap_size;
-+
-+ /* Remember PFN<->MFN relation for P2M update. */
-+ xen_add_remap_nonram(swap_addr, entry_end - swap_size,
-+ swap_size);
-+
-+ /* Order E820 table and merge entries. */
-+ e820__update_table(&xen_e820_table);
-+
-+ return;
-+ }
-+
-+ entry++;
-+ }
-+
-+ xen_raw_console_write("No suitable area found for required E820 entry remapping action\n");
-+ BUG();
-+}
-+
-+/*
-+ * Look for non-RAM memory types in a specific guest physical area and move
-+ * those away if possible (ACPI NVS only for now).
-+ */
-+static void __init xen_e820_resolve_conflicts(phys_addr_t start,
-+ phys_addr_t size)
-+{
-+ struct e820_entry *entry;
-+ unsigned int mapcnt;
-+ phys_addr_t end;
-+
-+ if (!size)
-+ return;
-+
-+ end = start + size;
-+ entry = xen_e820_table.entries;
-+
-+ for (mapcnt = 0; mapcnt < xen_e820_table.nr_entries; mapcnt++) {
-+ if (entry->addr >= end)
-+ return;
-+
-+ if (entry->addr + entry->size > start &&
-+ entry->type == E820_TYPE_NVS)
-+ xen_e820_swap_entry_with_ram(entry);
-+
-+ entry++;
-+ }
-+}
-+
- /*
- * Check for an area in physical memory to be usable for non-movable purposes.
-- * An area is considered to usable if the used E820 map lists it to be RAM.
-+ * An area is considered to usable if the used E820 map lists it to be RAM or
-+ * some other type which can be moved to higher PFNs while keeping the MFNs.
- * In case the area is not usable, crash the system with an error message.
- */
- void __init xen_chk_is_e820_usable(phys_addr_t start, phys_addr_t size,
- const char *component)
- {
-+ xen_e820_resolve_conflicts(start, size);
-+
- if (!xen_is_e820_reserved(start, size))
- return;
-
---
-2.43.0
-