- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] preempt/dynamic: Fix setup_preempt_mode() return value
by Xia Fukun 27 Oct '23

27 Oct '23

From: Andrew Halaney <ahalaney(a)redhat.com> mainline inclusion from mainline-v6.5-rc7 commit 9ed20bafc85806ca6c97c9128cec46c3ef80ae86 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8BAX7 CVE: NA -------------------------------- __setup() callbacks expect 1 for success and 0 for failure. Correct the usage here to reflect that. Fixes: 826bfeb37bb4 ("preempt/dynamic: Support dynamic preempt with preempt= boot option") Reported-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Andrew Halaney <ahalaney(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20211203233203.133581-1-ahalaney@redhat.com Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- kernel/sched/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5d17bffffaf4..44cfb82b4f13 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5794,11 +5794,11 @@ static int __init setup_preempt_mode(char *str) int mode = sched_dynamic_mode(str); if (mode < 0) { pr_warn("Dynamic Preempt: unsupported mode: %s\n", str); - return 1; + return 0; } sched_dynamic_update(mode); - return 0; + return 1; } __setup("preempt=", setup_preempt_mode); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2022-44033
by Zhang Xiaoxu 27 Oct '23

27 Oct '23

Jiri Slaby (2): tty: ipwireless: move Kconfig entry to tty char: pcmcia: remove all the drivers Documentation/ioctl/ioctl-number.txt | 1 - Documentation/process/magic-number.rst | 1 - .../translations/zh_CN/magic-number.txt | 1 - MAINTAINERS | 17 - arch/powerpc/configs/ppc6xx_defconfig | 2 - drivers/char/Kconfig | 2 - drivers/char/Makefile | 1 - drivers/char/pcmcia/Kconfig | 67 - drivers/char/pcmcia/Makefile | 10 - drivers/char/pcmcia/cm4000_cs.c | 1920 -------- drivers/char/pcmcia/cm4040_cs.c | 685 --- drivers/char/pcmcia/cm4040_cs.h | 48 - drivers/char/pcmcia/scr24x_cs.c | 373 -- drivers/char/pcmcia/synclink_cs.c | 4305 ----------------- drivers/tty/Kconfig | 9 + include/linux/cm4000_cs.h | 11 - include/uapi/linux/cm4000_cs.h | 64 - 17 files changed, 9 insertions(+), 7508 deletions(-) delete mode 100644 drivers/char/pcmcia/Kconfig delete mode 100644 drivers/char/pcmcia/Makefile delete mode 100644 drivers/char/pcmcia/cm4000_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.h delete mode 100644 drivers/char/pcmcia/scr24x_cs.c delete mode 100644 drivers/char/pcmcia/synclink_cs.c delete mode 100644 include/linux/cm4000_cs.h delete mode 100644 include/uapi/linux/cm4000_cs.h -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS 0/2] CVE-2022-44033
by Zhang Xiaoxu 27 Oct '23

27 Oct '23

Jiri Slaby (2): tty: ipwireless: move Kconfig entry to tty char: pcmcia: remove all the drivers Documentation/process/magic-number.rst | 1 - .../it_IT/process/magic-number.rst | 1 - .../zh_CN/process/magic-number.rst | 1 - .../userspace-api/ioctl/ioctl-number.rst | 1 - MAINTAINERS | 17 - arch/powerpc/configs/ppc6xx_defconfig | 2 - drivers/char/Kconfig | 2 - drivers/char/Makefile | 1 - drivers/char/pcmcia/Kconfig | 68 - drivers/char/pcmcia/Makefile | 11 - drivers/char/pcmcia/cm4000_cs.c | 1912 -------- drivers/char/pcmcia/cm4040_cs.c | 685 --- drivers/char/pcmcia/cm4040_cs.h | 48 - drivers/char/pcmcia/scr24x_cs.c | 360 -- drivers/char/pcmcia/synclink_cs.c | 4304 ----------------- drivers/tty/Kconfig | 9 + include/linux/cm4000_cs.h | 11 - include/uapi/linux/cm4000_cs.h | 64 - 18 files changed, 9 insertions(+), 7489 deletions(-) delete mode 100644 drivers/char/pcmcia/Kconfig delete mode 100644 drivers/char/pcmcia/Makefile delete mode 100644 drivers/char/pcmcia/cm4000_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.h delete mode 100644 drivers/char/pcmcia/scr24x_cs.c delete mode 100644 drivers/char/pcmcia/synclink_cs.c delete mode 100644 include/linux/cm4000_cs.h delete mode 100644 include/uapi/linux/cm4000_cs.h -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS 0/2] CVE-2022-44033
by Zhang Xiaoxu 27 Oct '23

27 Oct '23

Jiri Slaby (2): tty: ipwireless: move Kconfig entry to tty char: pcmcia: remove all the drivers Documentation/process/magic-number.rst | 1 - .../it_IT/process/magic-number.rst | 1 - .../zh_CN/process/magic-number.rst | 1 - .../userspace-api/ioctl/ioctl-number.rst | 1 - MAINTAINERS | 17 - arch/powerpc/configs/ppc6xx_defconfig | 2 - drivers/char/Kconfig | 2 - drivers/char/Makefile | 1 - drivers/char/pcmcia/Kconfig | 68 - drivers/char/pcmcia/Makefile | 11 - drivers/char/pcmcia/cm4000_cs.c | 1912 -------- drivers/char/pcmcia/cm4040_cs.c | 685 --- drivers/char/pcmcia/cm4040_cs.h | 48 - drivers/char/pcmcia/scr24x_cs.c | 360 -- drivers/char/pcmcia/synclink_cs.c | 4304 ----------------- drivers/tty/Kconfig | 9 + include/linux/cm4000_cs.h | 11 - include/uapi/linux/cm4000_cs.h | 64 - 18 files changed, 9 insertions(+), 7489 deletions(-) delete mode 100644 drivers/char/pcmcia/Kconfig delete mode 100644 drivers/char/pcmcia/Makefile delete mode 100644 drivers/char/pcmcia/cm4000_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.c delete mode 100644 drivers/char/pcmcia/cm4040_cs.h delete mode 100644 drivers/char/pcmcia/scr24x_cs.c delete mode 100644 drivers/char/pcmcia/synclink_cs.c delete mode 100644 include/linux/cm4000_cs.h delete mode 100644 include/uapi/linux/cm4000_cs.h -- 2.34.1

2 3

[PATCH OLK-5.10 v4 0/6] Synchronize coresight driver bugfix patches to openEuler
by Junhao He 26 Oct '23

26 Oct '23

1. Fix memory leak coresight: Fix memory leak in acpi_buffer->pointer 2. Fix TRBE bug coresight: trbe: Fix TRBE potential sleep in atomic context coresight: trbe: Allocate platform data per device coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() 3. Fix ETR bug coresight: Fix run time warnings while reusing ETR buffer coresight: tmc-etr: Disable warnings for allocation failures Junhao He (2): coresight: Fix memory leak in acpi_buffer->pointer coresight: trbe: Fix TRBE potential sleep in atomic context Linu Cherian (1): coresight: Fix run time warnings while reusing ETR buffer Suzuki K Poulose (2): coresight: trbe: Allocate platform data per device coresight: tmc-etr: Disable warnings for allocation failures Wei Yongjun (1): coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() .../hwtracing/coresight/coresight-platform.c | 46 ++++++++++++------- .../hwtracing/coresight/coresight-tmc-etr.c | 23 +++++----- drivers/hwtracing/coresight/coresight-trbe.c | 41 ++++++++--------- 3 files changed, 62 insertions(+), 48 deletions(-) -- 2.33.0

2 7

[PATCH OLK-5.10 0/7] coresight: etm4x: Migrate ACPI AMBA devices to platform driver
by Junhao He 26 Oct '23

26 Oct '23

CoreSight ETM4x devices could be accessed either via MMIO (handled via amba_driver) or CPU system instructions (handled via platform driver). But this has the following issues : - Each new CPU comes up with its own PID and thus we need to keep on adding the "known" PIDs to get it working with AMBA driver. While the ETM4 architecture (and CoreSight architecture) defines way to identify a device as ETM4. Thus older kernels won't be able to "discover" a newer CPU, unless we add the PIDs. - With ACPI, the ETM4x devices have the same HID to identify the device irrespective of the mode of access. This creates a problem where two different drivers (both AMBA based driver and platform driver) would hook into the "HID" and could conflict. e.g., if AMBA driver gets hold of a non-MMIO device, the probe fails. If we have single driver hooked into the given "HID", we could handle them seamlessly, irrespective of the mode of access. - CoreSight is heavily dependent on the runtime power management. With ACPI, amba_driver doesn't get us anywhere with handling the power and thus one need to always turn the power ON to use them. Moving to platform driver gives us the power management for free. Due to all of the above, we are moving ACPI MMIO based etm4x devices to be supported via tha platform driver. The series makes the existing platform driver generic to handle both type of the access modes. Although existing AMBA driver would still continue to support DT based etm4x MMIO devices. Although some problems still remain, such as manually adding PIDs for all new AMBA DT based devices. Anshuman Khandual (4): coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier coresight: etm4x: Drop iomem 'base' argument from etm4_probe() coresight: etm4x: Drop pid argument from etm4_probe() coresight: etm4x: Change etm4_platform_driver driver for MMIO devices Chengchang Tang (1): RDMA/hns: Add support for RDMA VF over UBL Junhao He (1): Revert "coresight: ete: Add acpi match id for Hip09" Suzuki K Poulose (1): coresight: platform: acpi: Ignore the absence of graph -- 2.33.0

2 8

[PATCH OLK-5.10 v2 0/7] coresight: etm4x: Migrate ACPI AMBA devices to platform driver
by Junhao He 26 Oct '23

26 Oct '23

CoreSight ETM4x devices could be accessed either via MMIO (handled via amba_driver) or CPU system instructions (handled via platform driver). But this has the following issues : - Each new CPU comes up with its own PID and thus we need to keep on adding the "known" PIDs to get it working with AMBA driver. While the ETM4 architecture (and CoreSight architecture) defines way to identify a device as ETM4. Thus older kernels won't be able to "discover" a newer CPU, unless we add the PIDs. - With ACPI, the ETM4x devices have the same HID to identify the device irrespective of the mode of access. This creates a problem where two different drivers (both AMBA based driver and platform driver) would hook into the "HID" and could conflict. e.g., if AMBA driver gets hold of a non-MMIO device, the probe fails. If we have single driver hooked into the given "HID", we could handle them seamlessly, irrespective of the mode of access. - CoreSight is heavily dependent on the runtime power management. With ACPI, amba_driver doesn't get us anywhere with handling the power and thus one need to always turn the power ON to use them. Moving to platform driver gives us the power management for free. Due to all of the above, we are moving ACPI MMIO based etm4x devices to be supported via tha platform driver. The series makes the existing platform driver generic to handle both type of the access modes. Although existing AMBA driver would still continue to support DT based etm4x MMIO devices. Although some problems still remain, such as manually adding PIDs for all new AMBA DT based devices. Anshuman Khandual (4): coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier coresight: etm4x: Drop iomem 'base' argument from etm4_probe() coresight: etm4x: Drop pid argument from etm4_probe() coresight: etm4x: Change etm4_platform_driver driver for MMIO devices Junhao He (1): Revert "coresight: ete: Add acpi match id for Hip09" Suzuki K Poulose (2): coresight: platform: acpi: Ignore the absence of graph coresight: etm4x: Add ACPI support in platform driver drivers/acpi/acpi_amba.c | 1 - .../coresight/coresight-etm4x-core.c | 119 ++++++++++++++---- drivers/hwtracing/coresight/coresight-etm4x.h | 4 + .../hwtracing/coresight/coresight-platform.c | 6 +- include/linux/coresight.h | 59 +++++++++ 5 files changed, 162 insertions(+), 27 deletions(-) -- 2.33.0

1 7

[PATCH openEuler-1.0-LTS 0/2] Expose SVE2 features for userspace
by Yu Liao 26 Oct '23

26 Oct '23

Andrew Murray (1): arm64: HWCAP: add support for AT_HWCAP2 Dave Martin (1): arm64: Expose SVE2 features for userspace Documentation/arm64/cpu-feature-registers.txt | 16 ++++ Documentation/arm64/elf_hwcaps.txt | 37 ++++++++- Documentation/arm64/sve.txt | 17 ++++ arch/arm64/Kconfig | 3 + arch/arm64/crypto/aes-ce-ccm-glue.c | 2 +- arch/arm64/crypto/aes-neonbs-glue.c | 2 +- arch/arm64/crypto/chacha20-neon-glue.c | 2 +- arch/arm64/crypto/ghash-ce-glue.c | 6 +- arch/arm64/crypto/sha256-glue.c | 4 +- arch/arm64/include/asm/cpufeature.h | 22 +++--- arch/arm64/include/asm/hwcap.h | 55 ++++++++++++- arch/arm64/include/asm/sysreg.h | 14 ++++ arch/arm64/include/uapi/asm/hwcap.h | 12 ++- arch/arm64/kernel/cpufeature.c | 77 +++++++++++-------- arch/arm64/kernel/cpuinfo.c | 12 ++- arch/arm64/kernel/fpsimd.c | 4 +- drivers/clocksource/arm_arch_timer.c | 8 ++ 17 files changed, 236 insertions(+), 57 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2023-5717
by Yang Jihong 26 Oct '23

26 Oct '23

Peter Zijlstra (1): perf: Disallow mis-matched inherited group reads Yang Jihong (1): perf: Fix kabi breakage in struct perf_event include/linux/perf_event.h | 4 ++++ kernel/events/core.c | 40 ++++++++++++++++++++++++++++++++------ 2 files changed, 38 insertions(+), 6 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 1/2] perf: Disallow mis-matched inherited group reads
by Yang Jihong 26 Oct '23

26 Oct '23

From: Peter Zijlstra <peterz(a)infradead.org> stable inclusion from stable-v4.19.297 commit a714491fa92d2068358dd603cc50bf2062517bd8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8B1X3 CVE: CVE-2023-5717 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 32671e3799ca2e4590773fd0e63aaa4229e50c06 upstream. Because group consistency is non-atomic between parent (filedesc) and children (inherited) events, it is possible for PERF_FORMAT_GROUP read() to try and sum non-matching counter groups -- with non-sensical results. Add group_generation to distinguish the case where a parent group removes and adds an event and thus has the same number, but a different configuration of events as inherited groups. This became a problem when commit fa8c269353d5 ("perf/core: Invert perf_read_group() loops") flipped the order of child_list and sibling_list. Previously it would iterate the group (sibling_list) first, and for each sibling traverse the child_list. In this order, only the group composition of the parent is relevant. By flipping the order the group composition of the child (inherited) events becomes an issue and the mis-match in group composition becomes evident. That said; even prior to this commit, while reading of a group that is not equally inherited was not broken, it still made no sense. (Ab)use ECHILD as error return to indicate issues with child process group composition. Fixes: fa8c269353d5 ("perf/core: Invert perf_read_group() loops") Reported-by: Budimir Markovic <markovicbudimir(a)gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20231018115654.GK33217@noisy.programming.kicks-as… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> --- include/linux/perf_event.h | 1 + kernel/events/core.c | 40 ++++++++++++++++++++++++++++++++------ 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 514962a49c62..a4bee4a4ae13 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -622,6 +622,7 @@ struct perf_event { /* The cumulative AND of all event_caps for events in this group. */ int group_caps; + unsigned int group_generation; struct perf_event *group_leader; struct pmu *pmu; void *pmu_private; diff --git a/kernel/events/core.c b/kernel/events/core.c index 5407c5ef7da8..a49860879777 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -1843,6 +1843,7 @@ static void perf_group_attach(struct perf_event *event) list_add_tail(&event->sibling_list, &group_leader->sibling_list); group_leader->nr_siblings++; + group_leader->group_generation++; perf_event__header_size(group_leader); @@ -1934,6 +1935,7 @@ static void perf_group_detach(struct perf_event *event) if (leader != event) { list_del_init(&event->sibling_list); event->group_leader->nr_siblings--; + event->group_leader->group_generation++; goto out; } @@ -4761,7 +4763,7 @@ static int __perf_read_group_add(struct perf_event *leader, u64 read_format, u64 *values) { struct perf_event_context *ctx = leader->ctx; - struct perf_event *sub; + struct perf_event *sub, *parent; unsigned long flags; int n = 1; /* skip @nr */ int ret; @@ -4771,6 +4773,33 @@ static int __perf_read_group_add(struct perf_event *leader, return ret; raw_spin_lock_irqsave(&ctx->lock, flags); + /* + * Verify the grouping between the parent and child (inherited) + * events is still in tact. + * + * Specifically: + * - leader->ctx->lock pins leader->sibling_list + * - parent->child_mutex pins parent->child_list + * - parent->ctx->mutex pins parent->sibling_list + * + * Because parent->ctx != leader->ctx (and child_list nests inside + * ctx->mutex), group destruction is not atomic between children, also + * see perf_event_release_kernel(). Additionally, parent can grow the + * group. + * + * Therefore it is possible to have parent and child groups in a + * different configuration and summing over such a beast makes no sense + * what so ever. + * + * Reject this. + */ + parent = leader->parent; + if (parent && + (parent->group_generation != leader->group_generation || + parent->nr_siblings != leader->nr_siblings)) { + ret = -ECHILD; + goto unlock; + } /* * Since we co-schedule groups, {enabled,running} times of siblings @@ -4800,8 +4829,9 @@ static int __perf_read_group_add(struct perf_event *leader, values[n++] = primary_event_id(sub); } +unlock: raw_spin_unlock_irqrestore(&ctx->lock, flags); - return 0; + return ret; } static int perf_read_group(struct perf_event *event, @@ -4820,10 +4850,6 @@ static int perf_read_group(struct perf_event *event, values[0] = 1 + leader->nr_siblings; - /* - * By locking the child_mutex of the leader we effectively - * lock the child list of all siblings.. XXX explain how. - */ mutex_lock(&leader->child_mutex); ret = __perf_read_group_add(leader, read_format, values); @@ -11679,6 +11705,8 @@ static int inherit_group(struct perf_event *parent_event, if (IS_ERR(child_ctr)) return PTR_ERR(child_ctr); } + if (leader) + leader->group_generation = parent_event->group_generation; return 0; } -- 2.34.1

2 3