- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] serial: core: Fix atomicity violation in uart_tiocmget
by Yi Yang 08 Nov '24

08 Nov '24

From: Gui-Dong Han <2045gemini(a)gmail.com> mainline inclusion from mainline-v6.8-rc3 commit 30926783a46841c2d1bbf3f74067ba85d304fd0d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB1MRY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In uart_tiocmget(): result = uport->mctrl; uart_port_lock_irq(uport); result |= uport->ops->get_mctrl(uport); uart_port_unlock_irq(uport); ... return result; In uart_update_mctrl(): uart_port_lock_irqsave(port, &flags); ... port->mctrl = (old & ~clear) | set; ... port->ops->set_mctrl(port, port->mctrl); ... uart_port_unlock_irqrestore(port, flags); An atomicity violation is identified due to the concurrent execution of uart_tiocmget() and uart_update_mctrl(). After assigning result = uport->mctrl, the mctrl value may change in uart_update_mctrl(), leading to a mismatch between the value returned by uport->ops->get_mctrl(uport) and the mctrl value previously read. This can result in uart_tiocmget() returning an incorrect value. This possible bug is found by an experimental static analysis tool developed by our team, BassCheck[1]. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported when our tool analyzes the source code of Linux 5.17. To address this issue, it is suggested to move the line result = uport->mctrl inside the uart_port_lock block to ensure atomicity and prevent the mctrl value from being altered during the execution of uart_tiocmget(). With this patch applied, our tool no longer reports the bug, with the kernel configuration allyesconfig for x86_64. Due to the absence of the requisite hardware, we are unable to conduct runtime testing of the patch. Therefore, our verification is solely based on code logic analysis. [1] https://sites.google.com/view/basscheck/ Fixes: c5f4644e6c8b ("[PATCH] Serial: Adjust serial locking") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> Link: https://lore.kernel.org/r/20240112113624.17048-1-2045gemini@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Commit 559c7ff4e324("serial: core: Use port lock wrappers") not merged, no functional change.] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 537bcd7c4941..d9d7506a9f6e 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1078,8 +1078,8 @@ static int uart_tiocmget(struct tty_struct *tty) goto out; if (!tty_io_error(tty)) { - result = uport->mctrl; spin_lock_irq(&uport->lock); + result = uport->mctrl; result |= uport->ops->get_mctrl(uport); spin_unlock_irq(&uport->lock); } -- 2.25.1

2 1

[PATCH OLK-6.6] Revert "perf callchain: Fix stitch LBR memory leaks"
by Peng Zhang 08 Nov '24

08 Nov '24

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> stable inclusion from stable-v6.6.56 commit 1e0f696469d6892959e621cebb3d2b722b816951 bugzilla: https://gitee.com/openeuler/kernel/issues/IB2ZN9 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- This reverts commit 42cd165b4cf89fb42b794d3a9ee792a7696c49b3 which is commit 599c19397b17d197fc1184bbc950f163a292efc9 upstream. It causes build breaks in the 6.6.y tree and should not have been applied, so revert it. Link: https://lore.kernel.org/r/894e27c0-c1e8-476d-ae16-11ab65853d1f@oracle.com Link: https://lore.kernel.org/r/f7bbebca-4da4-4270-ba6c-659a4c40b430@gmail.com Reported-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Reported-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kan Liang <kan.liang(a)linux.intel.com> Cc: Ian Rogers <irogers(a)google.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Anne Macedo <retpolanne(a)posteo.net> Cc: Changbin Du <changbin.du(a)huawei.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> --- tools/perf/util/machine.c | 17 ++--------------- tools/perf/util/thread.c | 4 ---- tools/perf/util/thread.h | 1 - 3 files changed, 2 insertions(+), 20 deletions(-) diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c index 24dead4e3065..7c6874804660 100644 --- a/tools/perf/util/machine.c +++ b/tools/perf/util/machine.c @@ -2536,12 +2536,8 @@ static void save_lbr_cursor_node(struct thread *thread, cursor->curr = cursor->first; else cursor->curr = cursor->curr->next; - - map_symbol__exit(&lbr_stitch->prev_lbr_cursor[idx].ms); memcpy(&lbr_stitch->prev_lbr_cursor[idx], cursor->curr, sizeof(struct callchain_cursor_node)); - lbr_stitch->prev_lbr_cursor[idx].ms.maps = maps__get(cursor->curr->ms.maps); - lbr_stitch->prev_lbr_cursor[idx].ms.map = map__get(cursor->curr->ms.map); lbr_stitch->prev_lbr_cursor[idx].valid = true; cursor->pos++; @@ -2752,9 +2748,6 @@ static bool has_stitched_lbr(struct thread *thread, memcpy(&stitch_node->cursor, &lbr_stitch->prev_lbr_cursor[i], sizeof(struct callchain_cursor_node)); - stitch_node->cursor.ms.maps = maps__get(lbr_stitch->prev_lbr_cursor[i].ms.maps); - stitch_node->cursor.ms.map = map__get(lbr_stitch->prev_lbr_cursor[i].ms.map); - if (callee) list_add(&stitch_node->node, &lbr_stitch->lists); else @@ -2778,8 +2771,6 @@ static bool alloc_lbr_stitch(struct thread *thread, unsigned int max_lbr) if (!thread__lbr_stitch(thread)->prev_lbr_cursor) goto free_lbr_stitch; - thread__lbr_stitch(thread)->prev_lbr_cursor_size = max_lbr + 1; - INIT_LIST_HEAD(&thread__lbr_stitch(thread)->lists); INIT_LIST_HEAD(&thread__lbr_stitch(thread)->free_lists); @@ -2835,12 +2826,8 @@ static int resolve_lbr_callchain_sample(struct thread *thread, max_lbr, callee); if (!stitched_lbr && !list_empty(&lbr_stitch->lists)) { - struct stitch_list *stitch_node; - - list_for_each_entry(stitch_node, &lbr_stitch->lists, node) - map_symbol__exit(&stitch_node->cursor.ms); - - list_splice_init(&lbr_stitch->lists, &lbr_stitch->free_lists); + list_replace_init(&lbr_stitch->lists, + &lbr_stitch->free_lists); } memcpy(&lbr_stitch->prev_sample, sample, sizeof(*sample)); } diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c index 6817b99e550b..61e9f449c725 100644 --- a/tools/perf/util/thread.c +++ b/tools/perf/util/thread.c @@ -478,7 +478,6 @@ void thread__free_stitch_list(struct thread *thread) return; list_for_each_entry_safe(pos, tmp, &lbr_stitch->lists, node) { - map_symbol__exit(&pos->cursor.ms); list_del_init(&pos->node); free(pos); } @@ -488,9 +487,6 @@ void thread__free_stitch_list(struct thread *thread) free(pos); } - for (unsigned int i = 0 ; i < lbr_stitch->prev_lbr_cursor_size; i++) - map_symbol__exit(&lbr_stitch->prev_lbr_cursor[i].ms); - zfree(&lbr_stitch->prev_lbr_cursor); free(thread__lbr_stitch(thread)); thread__set_lbr_stitch(thread, NULL); diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h index a5423f834dc9..0df775b5c110 100644 --- a/tools/perf/util/thread.h +++ b/tools/perf/util/thread.h @@ -28,7 +28,6 @@ struct lbr_stitch { struct list_head free_lists; struct perf_sample prev_sample; struct callchain_cursor_node *prev_lbr_cursor; - unsigned int prev_lbr_cursor_size; }; struct thread_rb_node { -- 2.25.1

2 1

[PATCH v7 OLK-5.10 0/7] mm: support poison recover for more
by Wupeng Ma 08 Nov '24

08 Nov '24

From: Ma Wupeng <mawupeng1(a)huawei.com> Add machine check safe support for cow & migrate_pages. Avoid kernel panic during arm64_do_kernel_sea if no valid info is reported. Changelog since v5: - cleanup in patch #6 Changelog since v3: - backport bugfix commit 88e4f525002b ("mm/hugetlb: add missing VM_FAULT_SET_HINDEX in hugetlb_wp") Changelog since v1: - fix incorrect patch format Kefeng Wang (2): mm: support poison recovery from copy_present_page() mm: support poison recovery from do_cow_fault() Liu Shixin (1): mm: hwpoison: support recovery from HugePage copy-on-write faults Ma Wupeng (2): arm64: mm: Add copy mc support for all migrate_page arm64: send sig fault for user task when apei_claim_sea fails Oscar Salvador (1): mm/hugetlb: add missing VM_FAULT_SET_HINDEX in hugetlb_wp Tong Tiangen (1): make copy_[user]_highpage_mc have return value arch/arm64/include/asm/page.h | 6 +-- arch/arm64/lib/copy_page_mc.S | 6 ++- arch/arm64/mm/copypage.c | 21 +++++--- arch/arm64/mm/fault.c | 17 +++++-- include/linux/highmem.h | 13 ++++- include/linux/mm.h | 8 ++-- mm/hugetlb.c | 7 ++- mm/memory.c | 90 +++++++++++++++++++++++------------ mm/migrate.c | 5 +- 9 files changed, 116 insertions(+), 57 deletions(-) -- 2.25.1

2 8

[PATCH OLK-5.10] blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
by Zheng Qixing 08 Nov '24

08 Nov '24

From: Omar Sandoval <osandov(a)fb.com> stable inclusion from stable-v5.10.228 commit 3bc6d0f8b70a9101456cf02ab99acb75254e1852 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB0ENF CVE: CVE-2024-50082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit e972b08b91ef48488bae9789f03cfedb148667fb upstream. We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait(). Fixes: 38cfb5a45ee0 ("blk-wbt: improve waking of tasks") Cc: stable(a)vger.kernel.org Signed-off-by: Omar Sandoval <osandov(a)fb.com> Acked-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Link: https://lore.kernel.org/r/d3bee2463a67b1ee597211823bf7ad3721c26e41.17290145… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/blk-rq-qos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-rq-qos.c b/block/blk-rq-qos.c index e83af7bc7591..26dd3e7bd00d 100644 --- a/block/blk-rq-qos.c +++ b/block/blk-rq-qos.c @@ -225,8 +225,8 @@ static int rq_qos_wake_function(struct wait_queue_entry *curr, data->got_token = true; smp_wmb(); - list_del_init(&curr->entry); wake_up_process(data->task); + list_del_init_careful(&curr->entry); return 1; } -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
by Zheng Qixing 08 Nov '24

08 Nov '24

From: Omar Sandoval <osandov(a)fb.com> stable inclusion from stable-v5.10.228 commit 3bc6d0f8b70a9101456cf02ab99acb75254e1852 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB0ENF CVE: CVE-2024-50082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit e972b08b91ef48488bae9789f03cfedb148667fb upstream. We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait(). Fixes: 38cfb5a45ee0 ("blk-wbt: improve waking of tasks") Cc: stable(a)vger.kernel.org Signed-off-by: Omar Sandoval <osandov(a)fb.com> Acked-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Link: https://lore.kernel.org/r/d3bee2463a67b1ee597211823bf7ad3721c26e41.17290145… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/blk-rq-qos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-rq-qos.c b/block/blk-rq-qos.c index e83af7bc7591..26dd3e7bd00d 100644 --- a/block/blk-rq-qos.c +++ b/block/blk-rq-qos.c @@ -225,8 +225,8 @@ static int rq_qos_wake_function(struct wait_queue_entry *curr, data->got_token = true; smp_wmb(); - list_del_init(&curr->entry); wake_up_process(data->task); + list_del_init_careful(&curr->entry); return 1; } -- 2.39.2

2 1

[openeuler:openEuler-1.0-LTS 1219/1219] drivers/misc/uacce/uacce.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 08 Nov '24

08 Nov '24

Hi Yu'an, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: bafa65a8c91fb9c99706d2d22210690199f95779 commit: 451823febcb610969f048556cedc41b5e08fafb1 [1219/1219] UACCE backport from mainline config: x86_64-buildonly-randconfig-001-20241025 (https://download.01.org/0day-ci/archive/20241108/202411081751.ofDiZRvj-lkp@…) compiler: clang version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241108/202411081751.ofDiZRvj-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202411081751.ofDiZRvj-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/misc/uacce/uacce.c:1032:16: warning: unused variable 'uacce' [-Wunused-variable] 1032 | struct uacce *uacce = UACCE_FROM_CDEV_ATTR(dev); | ^~~~~ drivers/misc/uacce/uacce.c:1046:16: warning: unused variable 'uacce' [-Wunused-variable] 1046 | struct uacce *uacce = UACCE_FROM_CDEV_ATTR(dev); | ^~~~~ 2 warnings generated. drivers/misc/uacce/uacce.c:60: warning: Function parameter or member 'dev' not described in 'dev_to_uacce' drivers/misc/uacce/uacce.c:81: warning: Function parameter or member 'uacce' not described in 'uacce_hw_err_isolate' drivers/misc/uacce/uacce.c:140: warning: Function parameter or member 'q' not described in 'uacce_wake_up' >> drivers/misc/uacce/uacce.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 00/10] fs: 6.6 performance improve patches
by Jinjie Ruan 08 Nov '24

08 Nov '24

6.6 performance improve patches, with mm��fs , Unixbench Process create improve 1 ~ 3%��lmbench exec/shell/fork improve 1.4 ~ 1.9%, 0.7 ~ 2.2%, 2 ~ 3.8% respectively. libmicro fork10/exec/sys improves 1.5%, 3.9 ~ 5.8%, 3.7 ~ 5.3%. Christian Brauner (4): fs: move audit parent inode fs: pull up trailing slashes check for O_CREAT fs: remove audit dummy context check fs: rearrange general fastpath check now that O_CREAT uses it David Hildenbrand (1): mm/rmap: minimize folio->_nr_pages_mapped updates when batching PTE (un)mapping Jeff Layton (1): fs: try an opportunistic lookup for O_CREAT opens too Liam R. Howlett (1): maple_tree: remove rcu_read_lock() from mt_validate() Mateusz Guzik (1): mm: batch unlink_file_vma calls in free_pgd_range Yu Ma (2): fs/file.c: add fast path in find_next_fd() fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() fs/file.c | 43 +++++++++++++++++++--------------- fs/namei.c | 61 +++++++++++++++++++++++++++++++++++++----------- lib/maple_tree.c | 7 ++---- mm/internal.h | 10 ++++++++ mm/memory.c | 10 ++++++-- mm/mmap.c | 41 ++++++++++++++++++++++++++++++++ mm/rmap.c | 27 +++++++++++---------- 7 files changed, 145 insertions(+), 54 deletions(-) -- 2.34.1

2 11

[PATCH OLK-6.6] blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
by Zheng Qixing 08 Nov '24

08 Nov '24

From: Omar Sandoval <osandov(a)fb.com> stable inclusion from stable-v6.6.58 commit 4c5b123ab289767afe940389dbb963c5c05e594e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB0ENF CVE: CVE-2024-50082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- commit e972b08b91ef48488bae9789f03cfedb148667fb upstream. We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait(). Fixes: 38cfb5a45ee0 ("blk-wbt: improve waking of tasks") Cc: stable(a)vger.kernel.org Signed-off-by: Omar Sandoval <osandov(a)fb.com> Acked-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Link: https://lore.kernel.org/r/d3bee2463a67b1ee597211823bf7ad3721c26e41.17290145… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/blk-rq-qos.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-rq-qos.c b/block/blk-rq-qos.c index dd7310c94713..dc510f493ba5 100644 --- a/block/blk-rq-qos.c +++ b/block/blk-rq-qos.c @@ -219,8 +219,8 @@ static int rq_qos_wake_function(struct wait_queue_entry *curr, data->got_token = true; smp_wmb(); - list_del_init(&curr->entry); wake_up_process(data->task); + list_del_init_careful(&curr->entry); return 1; } -- 2.39.2

2 1

[PATCH OLK-6.6] smb: client: fix possible double free in smb2_set_ea()
by Yifan Qiao 08 Nov '24

08 Nov '24

From: Su Hui <suhui(a)nfschina.com> stable inclusion from stable-v6.6.32 commit b1813c220b76f60b1727984794377c4aa849d4c1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB2SWG CVE: CVE-2024-50152 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 19ebc1e6cab334a8193398d4152deb76019b5d34 ] Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea' -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Su Hui <suhui(a)nfschina.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/smb/client/smb2ops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index acd5d7d79352..38de3d593abc 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -1122,7 +1122,7 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon, struct cifs_fid fid; unsigned int size[1]; void *data[1]; - struct smb2_file_full_ea_info *ea = NULL; + struct smb2_file_full_ea_info *ea; struct smb2_query_info_rsp *rsp; int rc, used_len = 0; int retries = 0, cur_sleep = 1; @@ -1143,6 +1143,7 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon, if (!utf16_path) return -ENOMEM; + ea = NULL; resp_buftype[0] = resp_buftype[1] = resp_buftype[2] = CIFS_NO_BUFFER; vars = kzalloc(sizeof(*vars), GFP_KERNEL); if (!vars) { -- 2.39.2

2 1

[PATCH v6 OLK-5.10 0/7] mm: support poison recover for more
by Wupeng Ma 08 Nov '24

08 Nov '24

From: Ma Wupeng <mawupeng1(a)huawei.com> Add machine check safe support for cow & migrate_pages. Avoid kernel panic during arm64_do_kernel_sea if no valid info is reported. Changelog since v5: - cleanup in patch #6 Changelog since v3: - backport bugfix commit 88e4f525002b ("mm/hugetlb: add missing VM_FAULT_SET_HINDEX in hugetlb_wp") Changelog since v1: - fix incorrect patch format Kefeng Wang (2): mm: support poison recovery from copy_present_page() mm: support poison recovery from do_cow_fault() Liu Shixin (1): mm: hwpoison: support recovery from HugePage copy-on-write faults Ma Wupeng (2): arm64: mm: Add copy mc support for all migrate_page arm64: send sig fault for user task when apei_claim_sea fails Oscar Salvador (1): mm/hugetlb: add missing VM_FAULT_SET_HINDEX in hugetlb_wp Tong Tiangen (1): make copy_[user]_highpage_mc have return value arch/arm64/include/asm/page.h | 6 +-- arch/arm64/lib/copy_page_mc.S | 6 ++- arch/arm64/mm/copypage.c | 21 +++++--- arch/arm64/mm/fault.c | 18 +++++-- include/linux/highmem.h | 13 ++++- include/linux/mm.h | 8 ++-- mm/hugetlb.c | 7 ++- mm/memory.c | 90 +++++++++++++++++++++++------------ mm/migrate.c | 5 +- 9 files changed, 118 insertions(+), 56 deletions(-) -- 2.25.1

2 8