- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] dm-bufio: fix sched in atomic context
by Li Lingfeng 29 Jul '25

29 Jul '25

From: Sheng Yong <shengyong1(a)xiaomi.com> mainline inclusion from mainline-v6.17-rc1 commit b1bf1a782fdf5c482215c0c661b5da98b8e75773 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPD56 CVE: CVE-2025-38496 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: <TASK> dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 </TASK> That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] Cc: stable(a)vger.kernel.org # v6.4+ Fixes: 450e8dee51aa ("dm bufio: improve concurrent IO performance") Signed-off-by: Wang Shuai <wangshuai12(a)xiaomi.com> Signed-off-by: Sheng Yong <shengyong1(a)xiaomi.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Conflicts: drivers/md/dm-bufio.c [Commit 9769378133bb ("dm-bufio: remove maximum age based eviction") removed the definition of __evict_many().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-bufio.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index 30ddfb21f658..376d2d8278f7 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -2701,7 +2701,11 @@ static unsigned long __evict_many(struct dm_bufio_client *c, __make_buffer_clean(b); __free_buffer_wake(b); - cond_resched(); + if (need_resched()) { + dm_bufio_unlock(c); + cond_resched(); + dm_bufio_lock(c); + } } return count; -- 2.46.1

2 1

[PATCH OLK-6.6] livepatch: fix insn length check
by Pan Taixi 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPCXQ ---------------------------------------- When livepatch checks the instruction length while ftrace is modifying the instruction, livepatch might read incorrect insn length. This tries to fix the issue by holding jump_label_lock() when doing insn check. Fixes: 4fe95df15c61 ("livepatch/core: Avoid conflict with static {call,key}") Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- kernel/livepatch/core.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index bb7ecc516b4a..6c5b3f52967a 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -21,6 +21,7 @@ #include <linux/completion.h> #include <linux/memory.h> #include <linux/rcupdate.h> +#include <linux/jump_label.h> #include <asm/cacheflush.h> #include "core.h" #ifdef CONFIG_LIVEPATCH_FTRACE @@ -1602,18 +1603,11 @@ static int check_address_conflict(struct klp_patch *patch) { struct klp_object *obj; struct klp_func *func; - int ret; + int ret = 0; void *start; void *end; - /* - * Locks seem required as comment of jump_label_text_reserved() said: - * Caller must hold jump_label_mutex. - * But looking into implementation of jump_label_text_reserved() and - * static_call_text_reserved(), call sites of every jump_label or static_call - * are checked, and they won't be changed after corresponding module inserted, - * so no need to take jump_label_lock and static_call_lock here. - */ + jump_label_lock(); klp_for_each_object(patch, obj) { klp_for_each_func(obj, func) { start = func->old_func; @@ -1622,17 +1616,21 @@ static int check_address_conflict(struct klp_patch *patch) if (ret) { pr_err("'%s' has static key in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } ret = static_call_text_reserved(start, end); if (ret) { pr_err("'%s' has static call in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } } } - return 0; +out: + jump_label_unlock(); + return ret; } static int state_show(struct seq_file *m, void *v) -- 2.34.1

2 1

[PATCH OLK-5.10] eventpoll: Fix return fixed cpu bug in set_prefetch_numa_cpu()
by Jinjie Ruan 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/release-management/issues/IC9Q31 -------------------------------- The original intention of set_prefetch_numa_cpu() was to randomly select a CPU from the pfi->related_cpu range based on fd. The function of cpumask_next(int n, const struct cpumask *srcp) is, in the given CPU mask "srcp", find the next CPU number that is set (i.e., set to 1) starting from the specified position n. So cpumask_next() in set_prefetch_numa_cpu() will always return cpumask_first(&related_cpus) if the following conditions are met: fd % cpumask_weight(&related_cpus) < cpumask_first(&related_cpus) But use the calculated offset in cpumask_next() may also not be correct if the "related_cpus" is discontinuous. So count the nth cpu in "related_cpus" to return the prefetch cpu. Fixes: 7e1291339cb5 ("eventpoll: Support xcall async prefetch") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- fs/eventpoll.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index dd11e92994c9..4360444afb83 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -949,6 +949,20 @@ static void prefetch_work_fn(struct work_struct *work) trace_epoll_rc_ready(pfi->file, pfi->len); } +static int get_nth_cpu_in_cpumask(const struct cpumask *mask, int n) +{ + int count = 0; + int cpu; + + for_each_cpu(cpu, mask) { + if (count == n) + return cpu; + count++; + } + + return cpumask_first(mask); +} + static void set_prefetch_numa_cpu(struct prefetch_item *pfi, int fd) { int cur_cpu = smp_processor_id(); @@ -959,11 +973,9 @@ static void set_prefetch_numa_cpu(struct prefetch_item *pfi, int fd) cpumask_and(&pfi->related_cpus, cpu_cpu_mask(cur_cpu), cpu_online_mask); if (cpumask_intersects(&tmp, &pfi->related_cpus)) cpumask_and(&pfi->related_cpus, &pfi->related_cpus, &tmp); - cpu = cpumask_next(fd % cpumask_weight(&pfi->related_cpus), - &pfi->related_cpus); - if (cpu > cpumask_last(&pfi->related_cpus)) - cpu = cpumask_first(&pfi->related_cpus); - pfi->cpu = cpu; + + pfi->cpu = get_nth_cpu_in_cpumask(&pfi->related_cpus, + fd % cpumask_weight(&pfi->related_cpus)); } static struct prefetch_item *alloc_prefetch_item(struct epitem *epi) -- 2.34.1

2 1

[PATCH OLK-6.6] perf: Revert to requiring CAP_SYS_ADMIN for uprobes
by Luo Gengkun 29 Jul '25

29 Jul '25

From: Peter Zijlstra <peterz(a)infradead.org> stable inclusion from stable-v6.6.99 commit 183bdb89af1b5193b1d1d9316986053b15ca6fa4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICOXOV CVE: CVE-2025-38466 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ba677dbe77af5ffe6204e0f3f547f3ba059c6302 ] Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes. Fixes: c9e0924e5c2b ("perf/core: open access to probes for CAP_PERFMON privileged process") Reported-by: Jann Horn <jannh(a)google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/CAG48ez1n4520sq0XrWYDHKiKxE_+WCfAK+qt9qkY4ZiBGmL-… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index b99ffd733674..18e52ceb7dd8 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -10425,7 +10425,7 @@ static int perf_uprobe_event_init(struct perf_event *event) if (event->attr.type != perf_uprobe.type) return -ENOENT; - if (!perfmon_capable()) + if (!capable(CAP_SYS_ADMIN)) return -EACCES; /* -- 2.34.1

2 1

[PATCH OLK-5.10] perf: Revert to requiring CAP_SYS_ADMIN for uprobes
by Luo Gengkun 29 Jul '25

29 Jul '25

From: Peter Zijlstra <peterz(a)infradead.org> stable inclusion from stable-v5.10.240 commit d7ef1afd5b3f43f4924326164cee5397b66abd9c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICOXOV CVE: CVE-2025-38466 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ba677dbe77af5ffe6204e0f3f547f3ba059c6302 ] Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes. Fixes: c9e0924e5c2b ("perf/core: open access to probes for CAP_PERFMON privileged process") Reported-by: Jann Horn <jannh(a)google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/CAG48ez1n4520sq0XrWYDHKiKxE_+WCfAK+qt9qkY4ZiBGmL-… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 7b185e630e08..1ca8ecdabbe3 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9667,7 +9667,7 @@ static int perf_uprobe_event_init(struct perf_event *event) if (event->attr.type != perf_uprobe.type) return -ENOENT; - if (!perfmon_capable()) + if (!capable(CAP_SYS_ADMIN)) return -EACCES; /* -- 2.34.1

2 1

[PATCH OLK-6.6] perf: Revert to requiring CAP_SYS_ADMIN for uprobes
by Luo Gengkun 29 Jul '25

29 Jul '25

From: Peter Zijlstra <peterz(a)infradead.org> stable inclusion from stable-v6.6.99 commit 183bdb89af1b5193b1d1d9316986053b15ca6fa4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICOXOV CVE: CVE-2025-38466 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… [ Upstream commit ba677dbe77af5ffe6204e0f3f547f3ba059c6302 ] Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes. Fixes: c9e0924e5c2b ("perf/core: open access to probes for CAP_PERFMON privileged process") Reported-by: Jann Horn <jannh(a)google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/CAG48ez1n4520sq0XrWYDHKiKxE_+WCfAK+qt9qkY4ZiBGmL-… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index b99ffd733674..18e52ceb7dd8 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -10425,7 +10425,7 @@ static int perf_uprobe_event_init(struct perf_event *event) if (event->attr.type != perf_uprobe.type) return -ENOENT; - if (!perfmon_capable()) + if (!capable(CAP_SYS_ADMIN)) return -EACCES; /* -- 2.34.1

2 1

[PATCH OLK-6.6] video: screen_info: Relocate framebuffers behind PCI bridges
by Pu Lehui 29 Jul '25

29 Jul '25

From: Thomas Zimmermann <tzimmermann(a)suse.de> stable inclusion from stable-v6.6.95 commit cc3cc41ed67054a03134bea42408c720eec0fa04 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICOXM7 CVE: CVE-2025-38427 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream. Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> Reported-by: "Ivan T. Ivanov" <iivanov(a)suse.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696 Tested-by: "Ivan T. Ivanov" <iivanov(a)suse.de> Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.9+ Link: https://lore.kernel.org/r/20250528080234.7380-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/video/screen_info_pci.c | 79 +++++++++++++++++++++------------ 1 file changed, 50 insertions(+), 29 deletions(-) diff --git a/drivers/video/screen_info_pci.c b/drivers/video/screen_info_pci.c index 6c5833517141..66bfc1d0a6dc 100644 --- a/drivers/video/screen_info_pci.c +++ b/drivers/video/screen_info_pci.c @@ -7,8 +7,8 @@ static struct pci_dev *screen_info_lfb_pdev; static size_t screen_info_lfb_bar; -static resource_size_t screen_info_lfb_offset; -static struct resource screen_info_lfb_res = DEFINE_RES_MEM(0, 0); +static resource_size_t screen_info_lfb_res_start; // original start of resource +static resource_size_t screen_info_lfb_offset; // framebuffer offset within resource static bool __screen_info_relocation_is_valid(const struct screen_info *si, struct resource *pr) { @@ -31,7 +31,7 @@ void screen_info_apply_fixups(void) if (screen_info_lfb_pdev) { struct resource *pr = &screen_info_lfb_pdev->resource[screen_info_lfb_bar]; - if (pr->start != screen_info_lfb_res.start) { + if (pr->start != screen_info_lfb_res_start) { if (__screen_info_relocation_is_valid(si, pr)) { /* * Only update base if we have an actual @@ -47,46 +47,67 @@ void screen_info_apply_fixups(void) } } +static int __screen_info_lfb_pci_bus_region(const struct screen_info *si, unsigned int type, + struct pci_bus_region *r) +{ + u64 base, size; + + base = __screen_info_lfb_base(si); + if (!base) + return -EINVAL; + + size = __screen_info_lfb_size(si, type); + if (!size) + return -EINVAL; + + r->start = base; + r->end = base + size - 1; + + return 0; +} + static void screen_info_fixup_lfb(struct pci_dev *pdev) { unsigned int type; - struct resource res[SCREEN_INFO_MAX_RESOURCES]; - size_t i, numres; + struct pci_bus_region bus_region; int ret; + struct resource r = { + .flags = IORESOURCE_MEM, + }; + const struct resource *pr; const struct screen_info *si = &screen_info; if (screen_info_lfb_pdev) return; // already found type = screen_info_video_type(si); - if (type != VIDEO_TYPE_EFI) - return; // only applies to EFI + if (!__screen_info_has_lfb(type)) + return; // only applies to EFI; maybe VESA - ret = screen_info_resources(si, res, ARRAY_SIZE(res)); + ret = __screen_info_lfb_pci_bus_region(si, type, &bus_region); if (ret < 0) return; - numres = ret; - for (i = 0; i < numres; ++i) { - struct resource *r = &res[i]; - const struct resource *pr; - - if (!(r->flags & IORESOURCE_MEM)) - continue; - pr = pci_find_resource(pdev, r); - if (!pr) - continue; - - /* - * We've found a PCI device with the framebuffer - * resource. Store away the parameters to track - * relocation of the framebuffer aperture. - */ - screen_info_lfb_pdev = pdev; - screen_info_lfb_bar = pr - pdev->resource; - screen_info_lfb_offset = r->start - pr->start; - memcpy(&screen_info_lfb_res, r, sizeof(screen_info_lfb_res)); - } + /* + * Translate the PCI bus address to resource. Account + * for an offset if the framebuffer is behind a PCI host + * bridge. + */ + pcibios_bus_to_resource(pdev->bus, &r, &bus_region); + + pr = pci_find_resource(pdev, &r); + if (!pr) + return; + + /* + * We've found a PCI device with the framebuffer + * resource. Store away the parameters to track + * relocation of the framebuffer aperture. + */ + screen_info_lfb_pdev = pdev; + screen_info_lfb_bar = pr - pdev->resource; + screen_info_lfb_offset = r.start - pr->start; + screen_info_lfb_res_start = bus_region.start; } DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16, screen_info_fixup_lfb); -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] Fix CVE-2025-38424
by Luo Gengkun 29 Jul '25

29 Jul '25

Peter Zijlstra (1): perf: Fix sample vs do_exit() Tetsuo Handa (1): perf/core: Fix WARN in perf_sigtrap() kernel/events/core.c | 21 ++++++++++++++------- kernel/exit.c | 17 +++++++++-------- 2 files changed, 23 insertions(+), 15 deletions(-) -- 2.34.1

2 3