From: Ran Xiaokai <ran.xiaokai(a)zte.com.cn>
mainline inclusion
from mainline-v6.7-rc1
commit 38685e2a0476127db766f81b1c06019ddc4c9ffa
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFL2
CVE: CVE-2023-52831
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
If a system has isolated CPUs via the "isolcpus=" command line parameter,
then an attempt to offline the last housekeeping CPU will result in a
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn()
rebuild_sched_domains_locked()
ndoms = generate_sched_domains(&doms, &attr);
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the
subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
Call trace:
build_sched_domains+0x120c/0x1408
partition_sched_domains_locked+0x234/0x880
rebuild_sched_domains_locked+0x37c/0x798
rebuild_sched_domains+0x30/0x58
cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080
partition_sched_domains_locked+0x318/0x880
rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last
last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a
target CPU for initiating the CPU unplug operation via the work queue.
Suggested-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Ran Xiaokai <ran.xiaokai(a)zte.com.cn>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Link: https://lore.kernel.org/r/202310171709530660462@zte.com.cn
Conflicts:
kernel/cpu.c
[commit 04d4e665a60902cf36e7ad39af1179cb5df542ad ("sched/isolation: Use single feature type while referring to housekeeping cpumask") was nos merged]
Signed-off-by: liwei <liwei728(a)huawei.com>
---
kernel/cpu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index d1d61f363a2c..ad58af7499e2 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1044,11 +1044,14 @@ static int cpu_down_maps_locked(unsigned int cpu, enum cpuhp_state target)
/*
* Ensure that the control task does not run on the to be offlined
* CPU to prevent a deadlock against cfs_b->period_timer.
+ * Also keep at least one housekeeping cpu onlined to avoid generating
+ * an empty sched_domain span.
*/
- cpu = cpumask_any_but(cpu_online_mask, cpu);
- if (cpu >= nr_cpu_ids)
- return -EBUSY;
- return work_on_cpu(cpu, __cpu_down_maps_locked, &work);
+ for_each_cpu_and(cpu, cpu_online_mask, housekeeping_cpumask(HK_FLAG_DOMAIN)) {
+ if (cpu != work.cpu)
+ return work_on_cpu(cpu, __cpu_down_maps_locked, &work);
+ }
+ return -EBUSY;
}
static int do_cpu_down(unsigned int cpu, enum cpuhp_state target)
--
2.25.1
From: Ran Xiaokai <ran.xiaokai(a)zte.com.cn>
mainline inclusion
from mainline-v6.7-rc1
commit 38685e2a0476127db766f81b1c06019ddc4c9ffa
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFL2
CVE: CVE-2023-52831
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
If a system has isolated CPUs via the "isolcpus=" command line parameter,
then an attempt to offline the last housekeeping CPU will result in a
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn()
rebuild_sched_domains_locked()
ndoms = generate_sched_domains(&doms, &attr);
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the
subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
Call trace:
build_sched_domains+0x120c/0x1408
partition_sched_domains_locked+0x234/0x880
rebuild_sched_domains_locked+0x37c/0x798
rebuild_sched_domains+0x30/0x58
cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080
partition_sched_domains_locked+0x318/0x880
rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last
last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a
target CPU for initiating the CPU unplug operation via the work queue.
Suggested-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Ran Xiaokai <ran.xiaokai(a)zte.com.cn>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Link: https://lore.kernel.org/r/202310171709530660462@zte.com.cn
Conflicts:
kernel/cpu.c
[commit 04d4e665a60902cf36e7ad39af1179cb5df542ad ("sched/isolation: Use single feature type while referring to housekeeping cpumask") was nos merged]
Signed-off-by: liwei <liwei728(a)huawei.com>
---
kernel/cpu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index fdd911b306e0..870ac4283f86 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1142,11 +1142,14 @@ static int cpu_down_maps_locked(unsigned int cpu, enum cpuhp_state target)
/*
* Ensure that the control task does not run on the to be offlined
* CPU to prevent a deadlock against cfs_b->period_timer.
+ * Also keep at least one housekeeping cpu onlined to avoid generating
+ * an empty sched_domain span.
*/
- cpu = cpumask_any_but(cpu_online_mask, cpu);
- if (cpu >= nr_cpu_ids)
- return -EBUSY;
- return work_on_cpu(cpu, __cpu_down_maps_locked, &work);
+ for_each_cpu_and(cpu, cpu_online_mask, housekeeping_cpumask(HK_FLAG_DOMAIN)) {
+ if (cpu != work.cpu)
+ return work_on_cpu(cpu, __cpu_down_maps_locked, &work);
+ }
+ return -EBUSY;
}
static int cpu_down(unsigned int cpu, enum cpuhp_state target)
--
2.25.1
From: Kory Maincent <kory.maincent(a)bootlin.com>
mainline inclusion
from mainline-v6.8-rc7
commit bbcc1c83f343e580c3aa1f2a8593343bf7b55bba
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8OH
CVE: CVE-2024-27408
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
The Linked list element and pointer are not stored in the same memory as
the eDMA controller register. If the doorbell register is toggled before
the full write of the linked list a race condition error will occur.
In remote setup we can only use a readl to the memory to assure the full
write has occurred.
Fixes: 7e4b8a4fbe2c ("dmaengine: Add Synopsys eDMA IP version 0 support")
Reviewed-by: Serge Semin <fancer.lancer(a)gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>
Signed-off-by: Kory Maincent <kory.maincent(a)bootlin.com>
Link: https://lore.kernel.org/r/20240129-b4-feature_hdma_mainline-v7-6-8e8c1acb7a…
Signed-off-by: Vinod Koul <vkoul(a)kernel.org>
Conflicts:
drivers/dma/dw-edma/dw-edma-v0-core.c
[wangxiongfeng: Remove the following check in the origin patch:
'if (!(chunk->chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL))'.
Because DW_EDMA_CHIP_LOCAL is not introduced, and there is no
member in struct dw_edma_chan. DW_EDMA_CHIP_LOCAL is only set
for driver DW_EDMA_CHIP_LOCAL in commit 939fbcd568fd ("PCI: dwc:
Add Root Port and Endpoint controller eDMA engine support", which
is not merged in 5.10. Also change 'vaddr.io' to 'vaddr' because
'vaddr.io' is not introduced and these two have the same meaning.
Refer to 16f8a08643b6 ("dmaengine: dw-edma: Add mem-mapped LL-entries
support")]
Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com>
---
drivers/dma/dw-edma/dw-edma-v0-core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c
index 692de47b1670..4016a3e07c7a 100644
--- a/drivers/dma/dw-edma/dw-edma-v0-core.c
+++ b/drivers/dma/dw-edma/dw-edma-v0-core.c
@@ -233,6 +233,19 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
SET_LL(&llp->llp_high, upper_32_bits(chunk->ll_region.paddr));
}
+static void dw_edma_v0_sync_ll_data(struct dw_edma_chunk *chunk)
+{
+ /*
+ * In case of remote eDMA engine setup, the DW PCIe RP/EP internal
+ * configuration registers and application memory are normally accessed
+ * over different buses. Ensure LL-data reaches the memory before the
+ * doorbell register is toggled by issuing the dummy-read from the remote
+ * LL memory in a hope that the MRd TLP will return only after the
+ * last MWr TLP is completed
+ */
+ readl(chunk->ll_region.vaddr);
+}
+
void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
{
struct dw_edma_chan *chan = chunk->chan;
@@ -262,6 +275,9 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
SET_CH(dw, chan->dir, chan->id, llp_high,
upper_32_bits(chunk->ll_region.paddr));
}
+
+ dw_edma_v0_sync_ll_data(chunk);
+
/* Doorbell */
SET_RW(dw, chan->dir, doorbell,
FIELD_PREP(EDMA_V0_DOORBELL_CH_MASK, chan->id));
--
2.20.1