Safety option to keep boot IRQs enabled. This
should never be necessary.
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
-index 47e8ee1f6429..6c7351c444b0 100644
+index c7a5718e5729..901f55b9ac64 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -287,6 +287,106 @@ static int __init pci_apply_final_quirks(void)
/*
* Decoding should be disabled for a PCI device during BAR sizing to avoid
* conflict. But doing so may cause problems on host bridge and perhaps other
-@@ -5075,6 +5175,8 @@ static const struct pci_dev_acs_enabled {
+@@ -5091,6 +5191,8 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_CAVIUM, 0xA060, pci_quirk_mf_endpoint_acs },
/* APM X-Gene */
{ PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
-index 855173c77581..80b4a639c32c 100644
+index 4811937f572d..8850f9be9044 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -10355,7 +10355,7 @@ static struct net_device *netdev_wait_allrefs_any(struct list_head *list)
--- /dev/null
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 18 Oct 2023 12:41:04 -0700
+Subject: [PATCH] KVM: nSVM: Advertise support for flush-by-ASID
+
+Advertise support for FLUSHBYASID when nested SVM is enabled, as KVM can
+always emulate flushing TLB entries for a vmcb12 ASID, e.g. by running L2
+with a new, fresh ASID in vmcb02. Some modern hypervisors, e.g. VMWare
+Workstation 17, require FLUSHBYASID support and will refuse to run if it's
+not present.
+
+Punt on proper support, as "Honor L1's request to flush an ASID on nested
+VMRUN" is one of the TODO items in the (incomplete) list of issues that
+need to be addressed in order for KVM to NOT do a full TLB flush on every
+nested SVM transition (see nested_svm_transition_tlb_flush()).
+
+Reported-by: Stefan Sterz <s.sterz@proxmox.com>
+Closes: https://lkml.kernel.org/r/b9915c9c-4cf6-051a-2d91-44cc6380f455%40proxmox.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
+Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
+---
+ arch/x86/kvm/svm/svm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
+index 99832814341c..e8bb2bfd1ba1 100644
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -4985,6 +4985,7 @@ static __init void svm_set_cpu_caps(void)
+ if (nested) {
+ kvm_cpu_cap_set(X86_FEATURE_SVM);
+ kvm_cpu_cap_set(X86_FEATURE_VMCBCLEAN);
++ kvm_cpu_cap_set(X86_FEATURE_FLUSHBYASID);
+
+ if (nrips)
+ kvm_cpu_cap_set(X86_FEATURE_NRIPS);
+++ /dev/null
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Sean Christopherson <seanjc@google.com>
-Date: Wed, 18 Oct 2023 12:41:03 -0700
-Subject: [PATCH] Revert "nSVM: Check for reserved encodings of TLB_CONTROL in
- nested VMCB"
-
-Revert KVM's made-up consistency check on SVM's TLB control. The APM says
-that unsupported encodings are reserved, but the APM doesn't state that
-VMRUN checks for a supported encoding. Unless something is called out
-in "Canonicalization and Consistency Checks" or listed as MBZ (Must Be
-Zero), AMD behavior is typically to let software shoot itself in the foot.
-
-This reverts commit 174a921b6975ef959dd82ee9e8844067a62e3ec1.
-
-Fixes: 174a921b6975 ("nSVM: Check for reserved encodings of TLB_CONTROL in nested VMCB")
-Reported-by: Stefan Sterz <s.sterz@proxmox.com>
-Closes: https://lkml.kernel.org/r/b9915c9c-4cf6-051a-2d91-44cc6380f455%40proxmox.com
-Cc: stable@vger.kernel.org
-Signed-off-by: Sean Christopherson <seanjc@google.com>
-Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
----
- arch/x86/kvm/svm/nested.c | 15 ---------------
- 1 file changed, 15 deletions(-)
-
-diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
-index 36482780a42f..43481f26a34b 100644
---- a/arch/x86/kvm/svm/nested.c
-+++ b/arch/x86/kvm/svm/nested.c
-@@ -247,18 +247,6 @@ static bool nested_svm_check_bitmap_pa(struct kvm_vcpu *vcpu, u64 pa, u32 size)
- kvm_vcpu_is_legal_gpa(vcpu, addr + size - 1);
- }
-
--static bool nested_svm_check_tlb_ctl(struct kvm_vcpu *vcpu, u8 tlb_ctl)
--{
-- /* Nested FLUSHBYASID is not supported yet. */
-- switch(tlb_ctl) {
-- case TLB_CONTROL_DO_NOTHING:
-- case TLB_CONTROL_FLUSH_ALL_ASID:
-- return true;
-- default:
-- return false;
-- }
--}
--
- static bool __nested_vmcb_check_controls(struct kvm_vcpu *vcpu,
- struct vmcb_ctrl_area_cached *control)
- {
-@@ -278,9 +266,6 @@ static bool __nested_vmcb_check_controls(struct kvm_vcpu *vcpu,
- IOPM_SIZE)))
- return false;
-
-- if (CC(!nested_svm_check_tlb_ctl(vcpu, control->tlb_ctl)))
-- return false;
--
- if (CC((control->int_ctl & V_NMI_ENABLE_MASK) &&
- !vmcb12_is_intercept(control, INTERCEPT_NMI))) {
- return false;
+++ /dev/null
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Sean Christopherson <seanjc@google.com>
-Date: Wed, 18 Oct 2023 12:41:04 -0700
-Subject: [PATCH] KVM: nSVM: Advertise support for flush-by-ASID
-
-Advertise support for FLUSHBYASID when nested SVM is enabled, as KVM can
-always emulate flushing TLB entries for a vmcb12 ASID, e.g. by running L2
-with a new, fresh ASID in vmcb02. Some modern hypervisors, e.g. VMWare
-Workstation 17, require FLUSHBYASID support and will refuse to run if it's
-not present.
-
-Punt on proper support, as "Honor L1's request to flush an ASID on nested
-VMRUN" is one of the TODO items in the (incomplete) list of issues that
-need to be addressed in order for KVM to NOT do a full TLB flush on every
-nested SVM transition (see nested_svm_transition_tlb_flush()).
-
-Reported-by: Stefan Sterz <s.sterz@proxmox.com>
-Closes: https://lkml.kernel.org/r/b9915c9c-4cf6-051a-2d91-44cc6380f455%40proxmox.com
-Signed-off-by: Sean Christopherson <seanjc@google.com>
-Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
-Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
----
- arch/x86/kvm/svm/svm.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
-index 99832814341c..e8bb2bfd1ba1 100644
---- a/arch/x86/kvm/svm/svm.c
-+++ b/arch/x86/kvm/svm/svm.c
-@@ -4985,6 +4985,7 @@ static __init void svm_set_cpu_caps(void)
- if (nested) {
- kvm_cpu_cap_set(X86_FEATURE_SVM);
- kvm_cpu_cap_set(X86_FEATURE_VMCBCLEAN);
-+ kvm_cpu_cap_set(X86_FEATURE_FLUSHBYASID);
-
- if (nrips)
- kvm_cpu_cap_set(X86_FEATURE_NRIPS);
--- /dev/null
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Thomas Lamprecht <t.lamprecht@proxmox.com>
+Date: Mon, 6 Nov 2023 10:17:02 +0100
+Subject: [PATCH] revert "memfd: improve userspace warnings for missing
+ exec-related flags".
+
+This warning is telling userspace developers to pass MFD_EXEC and
+MFD_NOEXEC_SEAL to memfd_create(). Commit 434ed3350f57 ("memfd: improve
+userspace warnings for missing exec-related flags") made the warning more
+frequent and visible in the hope that this would accelerate the fixing of
+errant userspace.
+
+But the overall effect is to generate far too much dmesg noise.
+
+Fixes: 434ed3350f57 ("memfd: improve userspace warnings for missing exec-related flags")
+Reported-by: Damian Tometzki <dtometzki@fedoraproject.org>
+Closes: https://lkml.kernel.org/r/ZPFzCSIgZ4QuHsSC@fedora.fritz.box
+Cc: Aleksa Sarai <cyphar@cyphar.com>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Daniel Verkamp <dverkamp@chromium.org>
+Cc: Jeff Xu <jeffxu@google.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+ (cherry picked from commit 2562d67b1bdf91c7395b0225d60fdeb26b4bc5a0)
+Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
+---
+ mm/memfd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/memfd.c b/mm/memfd.c
+index 2dba2cb6f0d0..1c077e98e116 100644
+--- a/mm/memfd.c
++++ b/mm/memfd.c
+@@ -282,7 +282,7 @@ static int check_sysctl_memfd_noexec(unsigned int *flags)
+ }
+
+ if (!(*flags & MFD_NOEXEC_SEAL) && sysctl >= MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED) {
+- pr_err_ratelimited(
++ pr_warn_once(
+ "%s[%d]: memfd_create() requires MFD_NOEXEC_SEAL with vm.memfd_noexec=%d\n",
+ current->comm, task_pid_nr(current), sysctl);
+ return -EACCES;
--- /dev/null
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 27 Oct 2023 16:40:47 -0400
+Subject: [PATCH] drm/amd: Fix UBSAN array-index-out-of-bounds for Powerplay
+ headers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+For pptable structs that use flexible array sizes, use flexible arrays.
+
+Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Acked-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry-picked from commit 49afe91370b86566857a3c2c39612cf098110885)
+Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
+---
+ .../drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h | 4 ++--
+ .../amd/pm/powerplay/hwmgr/vega10_pptable.h | 24 +++++++++----------
+ 2 files changed, 14 insertions(+), 14 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
+index e0e40b054c08..5ec564dbf339 100644
+--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
++++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
+@@ -367,7 +367,7 @@ typedef struct _ATOM_Tonga_VCE_State_Record {
+ typedef struct _ATOM_Tonga_VCE_State_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries;
+- ATOM_Tonga_VCE_State_Record entries[1];
++ ATOM_Tonga_VCE_State_Record entries[];
+ } ATOM_Tonga_VCE_State_Table;
+
+ typedef struct _ATOM_Tonga_PowerTune_Table {
+@@ -482,7 +482,7 @@ typedef struct _ATOM_Tonga_Hard_Limit_Record {
+ typedef struct _ATOM_Tonga_Hard_Limit_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries;
+- ATOM_Tonga_Hard_Limit_Record entries[1];
++ ATOM_Tonga_Hard_Limit_Record entries[];
+ } ATOM_Tonga_Hard_Limit_Table;
+
+ typedef struct _ATOM_Tonga_GPIO_Table {
+diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
+index 9c479bd9a786..a372abcd01be 100644
+--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
++++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
+@@ -129,7 +129,7 @@ typedef struct _ATOM_Vega10_State {
+ typedef struct _ATOM_Vega10_State_Array {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_State states[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_State states[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_State_Array;
+
+ typedef struct _ATOM_Vega10_CLK_Dependency_Record {
+@@ -169,37 +169,37 @@ typedef struct _ATOM_Vega10_GFXCLK_Dependency_Table {
+ typedef struct _ATOM_Vega10_MCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_MCLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_MCLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_MCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_SOCCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_SOCCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_DCEFCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_DCEFCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_PIXCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_PIXCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_DISPCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries.*/
+- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_DISPCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_PHYCLK_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries. */
+- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_PHYCLK_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_MM_Dependency_Record {
+@@ -213,7 +213,7 @@ typedef struct _ATOM_Vega10_MM_Dependency_Record {
+ typedef struct _ATOM_Vega10_MM_Dependency_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries */
+- ATOM_Vega10_MM_Dependency_Record entries[1]; /* Dynamically allocate entries */
++ ATOM_Vega10_MM_Dependency_Record entries[]; /* Dynamically allocate entries */
+ } ATOM_Vega10_MM_Dependency_Table;
+
+ typedef struct _ATOM_Vega10_PCIE_Record {
+@@ -225,7 +225,7 @@ typedef struct _ATOM_Vega10_PCIE_Record {
+ typedef struct _ATOM_Vega10_PCIE_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries */
+- ATOM_Vega10_PCIE_Record entries[1]; /* Dynamically allocate entries. */
++ ATOM_Vega10_PCIE_Record entries[]; /* Dynamically allocate entries. */
+ } ATOM_Vega10_PCIE_Table;
+
+ typedef struct _ATOM_Vega10_Voltage_Lookup_Record {
+@@ -235,7 +235,7 @@ typedef struct _ATOM_Vega10_Voltage_Lookup_Record {
+ typedef struct _ATOM_Vega10_Voltage_Lookup_Table {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries; /* Number of entries */
+- ATOM_Vega10_Voltage_Lookup_Record entries[1]; /* Dynamically allocate entries */
++ ATOM_Vega10_Voltage_Lookup_Record entries[]; /* Dynamically allocate entries */
+ } ATOM_Vega10_Voltage_Lookup_Table;
+
+ typedef struct _ATOM_Vega10_Fan_Table {
+@@ -329,7 +329,7 @@ typedef struct _ATOM_Vega10_VCE_State_Table
+ {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries;
+- ATOM_Vega10_VCE_State_Record entries[1];
++ ATOM_Vega10_VCE_State_Record entries[];
+ } ATOM_Vega10_VCE_State_Table;
+
+ typedef struct _ATOM_Vega10_PowerTune_Table {
+@@ -432,7 +432,7 @@ typedef struct _ATOM_Vega10_Hard_Limit_Table
+ {
+ UCHAR ucRevId;
+ UCHAR ucNumEntries;
+- ATOM_Vega10_Hard_Limit_Record entries[1];
++ ATOM_Vega10_Hard_Limit_Record entries[];
+ } ATOM_Vega10_Hard_Limit_Table;
+
+ typedef struct _Vega10_PPTable_Generic_SubTable_Header
+++ /dev/null
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Thomas Lamprecht <t.lamprecht@proxmox.com>
-Date: Mon, 6 Nov 2023 10:17:02 +0100
-Subject: [PATCH] revert "memfd: improve userspace warnings for missing
- exec-related flags".
-
-This warning is telling userspace developers to pass MFD_EXEC and
-MFD_NOEXEC_SEAL to memfd_create(). Commit 434ed3350f57 ("memfd: improve
-userspace warnings for missing exec-related flags") made the warning more
-frequent and visible in the hope that this would accelerate the fixing of
-errant userspace.
-
-But the overall effect is to generate far too much dmesg noise.
-
-Fixes: 434ed3350f57 ("memfd: improve userspace warnings for missing exec-related flags")
-Reported-by: Damian Tometzki <dtometzki@fedoraproject.org>
-Closes: https://lkml.kernel.org/r/ZPFzCSIgZ4QuHsSC@fedora.fritz.box
-Cc: Aleksa Sarai <cyphar@cyphar.com>
-Cc: Christian Brauner <brauner@kernel.org>
-Cc: Daniel Verkamp <dverkamp@chromium.org>
-Cc: Jeff Xu <jeffxu@google.com>
-Cc: Kees Cook <keescook@chromium.org>
-Cc: Shuah Khan <shuah@kernel.org>
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
- (cherry picked from commit 2562d67b1bdf91c7395b0225d60fdeb26b4bc5a0)
-Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
----
- mm/memfd.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/mm/memfd.c b/mm/memfd.c
-index 2dba2cb6f0d0..1c077e98e116 100644
---- a/mm/memfd.c
-+++ b/mm/memfd.c
-@@ -282,7 +282,7 @@ static int check_sysctl_memfd_noexec(unsigned int *flags)
- }
-
- if (!(*flags & MFD_NOEXEC_SEAL) && sysctl >= MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED) {
-- pr_err_ratelimited(
-+ pr_warn_once(
- "%s[%d]: memfd_create() requires MFD_NOEXEC_SEAL with vm.memfd_noexec=%d\n",
- current->comm, task_pid_nr(current), sysctl);
- return -EACCES;
+++ /dev/null
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Alex Deucher <alexander.deucher@amd.com>
-Date: Fri, 27 Oct 2023 16:40:47 -0400
-Subject: [PATCH] drm/amd: Fix UBSAN array-index-out-of-bounds for Powerplay
- headers
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-For pptable structs that use flexible array sizes, use flexible arrays.
-
-Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
-Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
-Acked-by: Christian König <christian.koenig@amd.com>
-Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-(cherry-picked from commit 49afe91370b86566857a3c2c39612cf098110885)
-Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
----
- .../drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h | 4 ++--
- .../amd/pm/powerplay/hwmgr/vega10_pptable.h | 24 +++++++++----------
- 2 files changed, 14 insertions(+), 14 deletions(-)
-
-diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
-index e0e40b054c08..5ec564dbf339 100644
---- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
-+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
-@@ -367,7 +367,7 @@ typedef struct _ATOM_Tonga_VCE_State_Record {
- typedef struct _ATOM_Tonga_VCE_State_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries;
-- ATOM_Tonga_VCE_State_Record entries[1];
-+ ATOM_Tonga_VCE_State_Record entries[];
- } ATOM_Tonga_VCE_State_Table;
-
- typedef struct _ATOM_Tonga_PowerTune_Table {
-@@ -482,7 +482,7 @@ typedef struct _ATOM_Tonga_Hard_Limit_Record {
- typedef struct _ATOM_Tonga_Hard_Limit_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries;
-- ATOM_Tonga_Hard_Limit_Record entries[1];
-+ ATOM_Tonga_Hard_Limit_Record entries[];
- } ATOM_Tonga_Hard_Limit_Table;
-
- typedef struct _ATOM_Tonga_GPIO_Table {
-diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
-index 9c479bd9a786..a372abcd01be 100644
---- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
-+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_pptable.h
-@@ -129,7 +129,7 @@ typedef struct _ATOM_Vega10_State {
- typedef struct _ATOM_Vega10_State_Array {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_State states[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_State states[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_State_Array;
-
- typedef struct _ATOM_Vega10_CLK_Dependency_Record {
-@@ -169,37 +169,37 @@ typedef struct _ATOM_Vega10_GFXCLK_Dependency_Table {
- typedef struct _ATOM_Vega10_MCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_MCLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_MCLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_MCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_SOCCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_SOCCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_DCEFCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_DCEFCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_PIXCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_PIXCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_DISPCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries.*/
-- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_DISPCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_PHYCLK_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries. */
-- ATOM_Vega10_CLK_Dependency_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_CLK_Dependency_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_PHYCLK_Dependency_Table;
-
- typedef struct _ATOM_Vega10_MM_Dependency_Record {
-@@ -213,7 +213,7 @@ typedef struct _ATOM_Vega10_MM_Dependency_Record {
- typedef struct _ATOM_Vega10_MM_Dependency_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries */
-- ATOM_Vega10_MM_Dependency_Record entries[1]; /* Dynamically allocate entries */
-+ ATOM_Vega10_MM_Dependency_Record entries[]; /* Dynamically allocate entries */
- } ATOM_Vega10_MM_Dependency_Table;
-
- typedef struct _ATOM_Vega10_PCIE_Record {
-@@ -225,7 +225,7 @@ typedef struct _ATOM_Vega10_PCIE_Record {
- typedef struct _ATOM_Vega10_PCIE_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries */
-- ATOM_Vega10_PCIE_Record entries[1]; /* Dynamically allocate entries. */
-+ ATOM_Vega10_PCIE_Record entries[]; /* Dynamically allocate entries. */
- } ATOM_Vega10_PCIE_Table;
-
- typedef struct _ATOM_Vega10_Voltage_Lookup_Record {
-@@ -235,7 +235,7 @@ typedef struct _ATOM_Vega10_Voltage_Lookup_Record {
- typedef struct _ATOM_Vega10_Voltage_Lookup_Table {
- UCHAR ucRevId;
- UCHAR ucNumEntries; /* Number of entries */
-- ATOM_Vega10_Voltage_Lookup_Record entries[1]; /* Dynamically allocate entries */
-+ ATOM_Vega10_Voltage_Lookup_Record entries[]; /* Dynamically allocate entries */
- } ATOM_Vega10_Voltage_Lookup_Table;
-
- typedef struct _ATOM_Vega10_Fan_Table {
-@@ -329,7 +329,7 @@ typedef struct _ATOM_Vega10_VCE_State_Table
- {
- UCHAR ucRevId;
- UCHAR ucNumEntries;
-- ATOM_Vega10_VCE_State_Record entries[1];
-+ ATOM_Vega10_VCE_State_Record entries[];
- } ATOM_Vega10_VCE_State_Table;
-
- typedef struct _ATOM_Vega10_PowerTune_Table {
-@@ -432,7 +432,7 @@ typedef struct _ATOM_Vega10_Hard_Limit_Table
- {
- UCHAR ucRevId;
- UCHAR ucNumEntries;
-- ATOM_Vega10_Hard_Limit_Record entries[1];
-+ ATOM_Vega10_Hard_Limit_Record entries[];
- } ATOM_Vega10_Hard_Limit_Table;
-
- typedef struct _Vega10_PPTable_Generic_SubTable_Header
--- /dev/null
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
+Date: Fri, 15 Dec 2023 16:49:50 +0530
+Subject: [PATCH] ext4: fallback to complex scan if aligned scan doesn't work
+
+Currently in case the goal length is a multiple of stripe size we use
+ext4_mb_scan_aligned() to find the stripe size aligned physical blocks.
+In case we are not able to find any, we again go back to calling
+ext4_mb_choose_next_group() to search for a different suitable block
+group. However, since the linear search always begins from the start,
+most of the times we end up with the same BG and the cycle continues.
+
+With large fliesystems, the CPU can be stuck in this loop for hours
+which can slow down the whole system. Hence, until we figure out a
+better way to continue the search (rather than starting from beginning)
+in ext4_mb_choose_next_group(), lets just fallback to
+ext4_mb_complex_scan_group() in case aligned scan fails, as it is much
+more likely to find the needed blocks.
+
+Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
+---
+ fs/ext4/mballoc.c | 21 +++++++++++++--------
+ 1 file changed, 13 insertions(+), 8 deletions(-)
+
+diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
+index 2690d47a9ea2..9ff8ea02f79d 100644
+--- a/fs/ext4/mballoc.c
++++ b/fs/ext4/mballoc.c
+@@ -2894,14 +2894,19 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
+ ac->ac_groups_scanned++;
+ if (cr == CR_POWER2_ALIGNED)
+ ext4_mb_simple_scan_group(ac, &e4b);
+- else if ((cr == CR_GOAL_LEN_FAST ||
+- cr == CR_BEST_AVAIL_LEN) &&
+- sbi->s_stripe &&
+- !(ac->ac_g_ex.fe_len %
+- EXT4_B2C(sbi, sbi->s_stripe)))
+- ext4_mb_scan_aligned(ac, &e4b);
+- else
+- ext4_mb_complex_scan_group(ac, &e4b);
++ else {
++ bool is_stripe_aligned = sbi->s_stripe &&
++ !(ac->ac_g_ex.fe_len %
++ EXT4_B2C(sbi, sbi->s_stripe));
++
++ if ((cr == CR_GOAL_LEN_FAST ||
++ cr == CR_BEST_AVAIL_LEN) &&
++ is_stripe_aligned)
++ ext4_mb_scan_aligned(ac, &e4b);
++
++ if (ac->ac_status == AC_STATUS_CONTINUE)
++ ext4_mb_complex_scan_group(ac, &e4b);
++ }
+
+ ext4_unlock_group(sb, group);
+ ext4_mb_unload_buddy(&e4b);
+++ /dev/null
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
-Date: Fri, 15 Dec 2023 16:49:50 +0530
-Subject: [PATCH] ext4: fallback to complex scan if aligned scan doesn't work
-
-Currently in case the goal length is a multiple of stripe size we use
-ext4_mb_scan_aligned() to find the stripe size aligned physical blocks.
-In case we are not able to find any, we again go back to calling
-ext4_mb_choose_next_group() to search for a different suitable block
-group. However, since the linear search always begins from the start,
-most of the times we end up with the same BG and the cycle continues.
-
-With large fliesystems, the CPU can be stuck in this loop for hours
-which can slow down the whole system. Hence, until we figure out a
-better way to continue the search (rather than starting from beginning)
-in ext4_mb_choose_next_group(), lets just fallback to
-ext4_mb_complex_scan_group() in case aligned scan fails, as it is much
-more likely to find the needed blocks.
-
-Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
----
- fs/ext4/mballoc.c | 21 +++++++++++++--------
- 1 file changed, 13 insertions(+), 8 deletions(-)
-
-diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
-index 5246b408cf0c..e3b942664842 100644
---- a/fs/ext4/mballoc.c
-+++ b/fs/ext4/mballoc.c
-@@ -2894,14 +2894,19 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
- ac->ac_groups_scanned++;
- if (cr == CR_POWER2_ALIGNED)
- ext4_mb_simple_scan_group(ac, &e4b);
-- else if ((cr == CR_GOAL_LEN_FAST ||
-- cr == CR_BEST_AVAIL_LEN) &&
-- sbi->s_stripe &&
-- !(ac->ac_g_ex.fe_len %
-- EXT4_B2C(sbi, sbi->s_stripe)))
-- ext4_mb_scan_aligned(ac, &e4b);
-- else
-- ext4_mb_complex_scan_group(ac, &e4b);
-+ else {
-+ bool is_stripe_aligned = sbi->s_stripe &&
-+ !(ac->ac_g_ex.fe_len %
-+ EXT4_B2C(sbi, sbi->s_stripe));
-+
-+ if ((cr == CR_GOAL_LEN_FAST ||
-+ cr == CR_BEST_AVAIL_LEN) &&
-+ is_stripe_aligned)
-+ ext4_mb_scan_aligned(ac, &e4b);
-+
-+ if (ac->ac_status == AC_STATUS_CONTINUE)
-+ ext4_mb_complex_scan_group(ac, &e4b);
-+ }
-
- ext4_unlock_group(sb, group);
- ext4_mb_unload_buddy(&e4b);
projects / pve-kernel.git / commitdiff