December 2024 - Linux-stable-mirror

[tip: x86/urgent] x86/fred: Clear WFE in missing-ENDBRANCH #CPs

by tip-bot2 for Xin Li (Intel)

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: dc81e556f2a017d681251ace21bf06c126d5a192 Gitweb: https://git.kernel.org/tip/dc81e556f2a017d681251ace21bf06c126d5a192 Author: Xin Li (Intel) <xin(a)zytor.com> AuthorDate: Wed, 13 Nov 2024 09:59:34 -08:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Sun, 29 Dec 2024 10:18:10 +01:00 x86/fred: Clear WFE in missing-ENDBRANCH #CPs An indirect branch instruction sets the CPU indirect branch tracker (IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted across the instruction boundary. When the decoder finds an inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP fault. For the "kernel IBT no ENDBR" selftest where #CPs are deliberately triggered, the WFE state of the interrupted context needs to be cleared to let execution continue. Otherwise when the CPU resumes from the instruction that just caused the previous #CP, another missing-ENDBRANCH #CP is raised and the CPU enters a dead loop. This is not a problem with IDT because it doesn't preserve WFE and IRET doesn't set WFE. But FRED provides space on the entry stack (in an expanded CS area) to save and restore the WFE state, thus the WFE state is no longer clobbered, so software must clear it. Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the !ibt_fatal code path when execution is allowed to continue. Clobbering WFE in any other circumstance is a security-relevant bug. [ dhansen: changelog rewording ] Fixes: a5f6c2ace997 ("x86/shstk: Add user control-protection fault handler") Signed-off-by: Xin Li (Intel) <xin(a)zytor.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20241113175934.3897541-1-xin%40zytor.com --- arch/x86/kernel/cet.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c index d2c732a..303bf74 100644 --- a/arch/x86/kernel/cet.c +++ b/arch/x86/kernel/cet.c @@ -81,6 +81,34 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code) static __ro_after_init bool ibt_fatal = true; +/* + * By definition, all missing-ENDBRANCH #CPs are a result of WFE && !ENDBR. + * + * For the kernel IBT no ENDBR selftest where #CPs are deliberately triggered, + * the WFE state of the interrupted context needs to be cleared to let execution + * continue. Otherwise when the CPU resumes from the instruction that just + * caused the previous #CP, another missing-ENDBRANCH #CP is raised and the CPU + * enters a dead loop. + * + * This is not a problem with IDT because it doesn't preserve WFE and IRET doesn't + * set WFE. But FRED provides space on the entry stack (in an expanded CS area) + * to save and restore the WFE state, thus the WFE state is no longer clobbered, + * so software must clear it. + */ +static void ibt_clear_fred_wfe(struct pt_regs *regs) +{ + /* + * No need to do any FRED checks. + * + * For IDT event delivery, the high-order 48 bits of CS are pushed + * as 0s into the stack, and later IRET ignores these bits. + * + * For FRED, a test to check if fred_cs.wfe is set would be dropped + * by compilers. + */ + regs->fred_cs.wfe = 0; +} + static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) { if ((error_code & CP_EC) != CP_ENDBR) { @@ -90,6 +118,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) if (unlikely(regs->ip == (unsigned long)&ibt_selftest_noendbr)) { regs->ax = 0; + ibt_clear_fred_wfe(regs); return; } @@ -97,6 +126,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) if (!ibt_fatal) { printk(KERN_DEFAULT CUT_HERE); __warn(__FILE__, __LINE__, (void *)regs->ip, TAINT_WARN, regs, NULL); + ibt_clear_fred_wfe(regs); return; } BUG();

1 week, 4 days

1
0
0 0

[tip: x86/urgent] virt: tdx-guest: Just leak decrypted memory on unrecoverable errors

by tip-bot2 for Li RongQing

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 27834971f616c5e154423c578fa95e0444444ce1 Gitweb: https://git.kernel.org/tip/27834971f616c5e154423c578fa95e0444444ce1 Author: Li RongQing <lirongqing(a)baidu.com> AuthorDate: Wed, 19 Jun 2024 19:18:01 +08:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Sun, 29 Dec 2024 10:18:44 +01:00 virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS") Signed-off-by: Li RongQing <lirongqing(a)baidu.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Reviewed-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240619111801.25630-1-lirongqing%40baidu.com --- drivers/virt/coco/tdx-guest/tdx-guest.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c index d7db6c8..224e7dd 100644 --- a/drivers/virt/coco/tdx-guest/tdx-guest.c +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c @@ -124,10 +124,8 @@ static void *alloc_quote_buf(void) if (!addr) return NULL; - if (set_memory_decrypted((unsigned long)addr, count)) { - free_pages_exact(addr, len); + if (set_memory_decrypted((unsigned long)addr, count)) return NULL; - } return addr; }

1 week, 4 days

1
0
0 0

[PATCH v7 1/5] libfs: Return ENOSPC when the directory offset range is exhausted

by cel＠kernel.org

From: Chuck Lever <chuck.lever(a)oracle.com> Testing shows that the EBUSY error return from mtree_alloc_cyclic() leaks into user space. The ERRORS section of "man creat(2)" says: > EBUSY O_EXCL was specified in flags and pathname refers > to a block device that is in use by the system > (e.g., it is mounted). ENOSPC is closer to what applications expect in this situation. Note that the normal range of simple directory offset values is 2..2^63, so hitting this error is going to be rare to impossible. Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") Cc: <stable(a)vger.kernel.org> # v6.9+ Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/libfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/libfs.c b/fs/libfs.c index 748ac5923154..3da58a92f48f 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -292,8 +292,8 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) ret = mtree_alloc_cyclic(&octx->mt, &offset, dentry, DIR_OFFSET_MIN, LONG_MAX, &octx->next_offset, GFP_KERNEL); - if (ret < 0) - return ret; + if (unlikely(ret < 0)) + return ret == -EBUSY ? -ENOSPC : ret; offset_set(dentry, offset); return 0; -- 2.47.0

1 week, 4 days

1
0
0 0

[PATCH] net/sctp: Prevent autoclose integer overflow in sctp_association_init()

by Nikolay Kuratov

While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow. Cc: stable(a)vger.kernel.org Fixes: 9f70f46bd4c7 ("sctp: properly latch and use autoclose value from sock to association") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- net/sctp/associola.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sctp/associola.c b/net/sctp/associola.c index c45c192b7878..0b0794f164cf 100644 --- a/net/sctp/associola.c +++ b/net/sctp/associola.c @@ -137,7 +137,8 @@ static struct sctp_association *sctp_association_init( = 5 * asoc->rto_max; asoc->timeouts[SCTP_EVENT_TIMEOUT_SACK] = asoc->sackdelay; - asoc->timeouts[SCTP_EVENT_TIMEOUT_AUTOCLOSE] = sp->autoclose * HZ; + asoc->timeouts[SCTP_EVENT_TIMEOUT_AUTOCLOSE] = + (unsigned long)sp->autoclose * HZ; /* Initializes the timers */ for (i = SCTP_EVENT_TIMEOUT_NONE; i < SCTP_NUM_TIMEOUT_TYPES; ++i) -- 2.34.1

1 week, 5 days

4
3
0 0

Re: Bug: slab-out-of-bounds in snd_seq_oss_synth_sysex

by Kun Hu

> > >> 2024年12月25日 13:37，Kun Hu <huk23(a)m.fudan.edu.cn> 写道： >> >> Hello, >> >>> BUG: KASAN: slab-out-of-bounds in snd_seq_oss_synth_sysex+0x5d1/0x6c0 sound/core/seq/oss/seq_oss_synth.c:516 >> >> We further analyzed the issue at line 516 in ./sound/core/seq/oss/seq_oss_synth.c. >> The slab-out-of-bounds crash occurs in line 509, when sysex->len = 128. Specifically, the write operation to dest[0] accesses memory beyond the bounds of sysex->buf (128 byte). >> To resolve this issue, we suggest adding 6 lines of code to validate the legality of the address write to sysex->buf before entering the loop: >> >> if (sysex->len >= MAX_SYSEX_BUFLEN) { >> sysex->len = 0; >> sysex->skip = 1; >> return -EINVAL; /* Exit early if sysex->len is out of bounds */ >> } >> >> If you fix this issue, please add the following tag to the commit: >> Reported-by: Kun Hu <huk23(a)m.fudan.edu.cn> >> >> ————— >> Thanks, >> Kun Hu >> >>> 2024年12月24日 19:16，Kun Hu <huk23(a)m.fudan.edu.cn> 写道： >>> >>> Hello, >>> >>> When using fuzzer tool to fuzz the latest Linux kernel, the following crash >>> was triggered. >>> >>> HEAD commit: 78d4f34e2115b517bcbfe7ec0d018bbbb6f9b0b8 >>> git tree: upstream >>> Console output:https://drive.google.com/file/d/17oCyKDW_kNhSW5Bbvm23vnpD1eo0MHFi/vi… >>> Kernel config: https://drive.google.com/file/d/1RhT5dFTs6Vx1U71PbpenN7TPtnPoa3NI/view?usp=… >>> C reproducer: https://drive.google.com/file/d/177HJht6a7-6F3YLudKb_d4kiPGd1VA_i/view?usp=… >>> Syzlang reproducer: https://drive.google.com/file/d/1AuP5UGGc47rEXXPuvjmCKgJ3d0U1P84j/view?usp=… >>> >>> >>> If you fix this issue, please add the following tag to the commit: >>> Reported-by: Kun Hu <huk23(a)m.fudan.edu.cn> >>> >>> ================================================================== >>> BUG: KASAN: slab-out-of-bounds in snd_seq_oss_synth_sysex+0x5d1/0x6c0 sound/core/seq/oss/seq_oss_synth.c:516 >>> Write of size 1 at addr ff1100000588e288 by task syz-executor411/824 >>> >>> CPU: 2 UID: 0 PID: 824 Comm: syz-executor411 Not tainted 6.13.0-rc3 #5 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 >>> Call Trace: >>> <TASK> >>> __dump_stack lib/dump_stack.c:94 [inline] >>> dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 >>> print_address_description mm/kasan/report.c:378 [inline] >>> print_report+0xcf/0x5f0 mm/kasan/report.c:489 >>> kasan_report+0x93/0xc0 mm/kasan/report.c:602 >>> snd_seq_oss_synth_sysex+0x5d1/0x6c0 sound/core/seq/oss/seq_oss_synth.c:516 >>> snd_seq_oss_process_event+0x46a/0x2620 sound/core/seq/oss/seq_oss_event.c:61 >>> insert_queue sound/core/seq/oss/seq_oss_rw.c:167 [inline] >>> snd_seq_oss_write+0x261/0x7f0 sound/core/seq/oss/seq_oss_rw.c:135 >>> odev_write+0x53/0xa0 sound/core/seq/oss/seq_oss.c:168 >>> vfs_write fs/read_write.c:677 [inline] >>> vfs_write+0x2e3/0x10f0 fs/read_write.c:659 >>> ksys_write+0x122/0x240 fs/read_write.c:731 >>> do_syscall_x64 arch/x86/entry/common.c:52 [inline] >>> do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83 >>> entry_SYSCALL_64_after_hwframe+0x77/0x7f >> > Hello, Is this issue being considered and is it possible that the value of sysex->len in line 509 of the snd_seq_oss_synth_sysex function could exceed 127 and thus be out of bounds? ——— Best Regards, Kun Hu

1 week, 5 days

2
2
0 0

+ mm-kmemleak-fix-percpu-memory-leak-detection-failure.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/kmemleak: fix percpu memory leak detection failure has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-kmemleak-fix-percpu-memory-leak-detection-failure.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Guo Weikang <guoweikang.kernel(a)gmail.com> Subject: mm/kmemleak: fix percpu memory leak detection failure Date: Fri, 27 Dec 2024 17:23:10 +0800 kmemleak_alloc_percpu gives an incorrect min_count parameter, causing percpu memory to be considered a gray object. Link: https://lkml.kernel.org/r/20241227092311.3572500-1-guoweikang.kernel@gmail.… Fixes: 8c8685928910 ("mm/kmemleak: use IS_ERR_PCPU() for pointer in the percpu address space") Signed-off-by: Guo Weikang <guoweikang.kernel(a)gmail.com> Acked-by: Uros Bizjak <ubizjak(a)gmail.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Guo Weikang <guoweikang.kernel(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kmemleak.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/kmemleak.c~mm-kmemleak-fix-percpu-memory-leak-detection-failure +++ a/mm/kmemleak.c @@ -1093,7 +1093,7 @@ void __ref kmemleak_alloc_percpu(const v pr_debug("%s(0x%px, %zu)\n", __func__, ptr, size); if (kmemleak_enabled && ptr && !IS_ERR_PCPU(ptr)) - create_object_percpu((__force unsigned long)ptr, size, 0, gfp); + create_object_percpu((__force unsigned long)ptr, size, 1, gfp); } EXPORT_SYMBOL_GPL(kmemleak_alloc_percpu); _ Patches currently in -mm which might be from guoweikang.kernel(a)gmail.com are mm-kmemleak-fix-percpu-memory-leak-detection-failure.patch mm-shmem-refactor-to-reuse-vfs_parse_monolithic_sep-for-option-parsing.patch mm-early_ioremap-add-null-pointer-checks-to-prevent-null-pointer-dereference.patch

1 week, 5 days

1
0
0 0

[PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled

by Suren Baghdasaryan

When memory allocation profiling is disabled there is no need to update current->alloc_tag and these manipulations add unnecessary overhead. Fix the overhead by skipping these extra updates. Fixes: b951aaff5035 ("mm: enable page allocation tagging") Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org --- include/linux/alloc_tag.h | 11 ++++++++--- lib/alloc_tag.c | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h index 0bbbe537c5f9..a946e0203e6d 100644 --- a/include/linux/alloc_tag.h +++ b/include/linux/alloc_tag.h @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {} #define alloc_hooks_tag(_tag, _do_alloc) \ ({ \ - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \ - typeof(_do_alloc) _res = _do_alloc; \ - alloc_tag_restore(_tag, _old); \ + typeof(_do_alloc) _res; \ + if (mem_alloc_profiling_enabled()) { \ + struct alloc_tag * __maybe_unused _old; \ + _old = alloc_tag_save(_tag); \ + _res = _do_alloc; \ + alloc_tag_restore(_tag, _old); \ + } else \ + _res = _do_alloc; \ _res; \ }) diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c index 7dcebf118a3e..4c373f444eb1 100644 --- a/lib/alloc_tag.c +++ b/lib/alloc_tag.c @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag); DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT, mem_alloc_profiling_key); +EXPORT_SYMBOL(mem_alloc_profiling_key); + DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed); struct alloc_tag_kernel_section kernel_tags = { NULL, 0 }; base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f -- 2.47.1.613.gc27f4b7a9f-goog

1 week, 5 days

3
12
0 0

FAILED: patch "[PATCH] mtd: rawnand: arasan: Fix missing de-registration of NAND" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 11e6831fd81468cf48155b9b3c11295c391da723 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024122708-spud-properly-0780@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 11e6831fd81468cf48155b9b3c11295c391da723 Mon Sep 17 00:00:00 2001 From: Maciej Andrzejewski <maciej.andrzejewski(a)m-works.net> Date: Mon, 2 Dec 2024 19:58:36 +0100 Subject: [PATCH] mtd: rawnand: arasan: Fix missing de-registration of NAND The NAND chip-selects are registered for the Arasan driver during initialization but are not de-registered when the driver is unloaded. As a result, if the driver is loaded again, the chip-selects remain registered and busy, making them unavailable for use. Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller") Cc: stable(a)vger.kernel.org Signed-off-by: Maciej Andrzejewski ICEYE <maciej.andrzejewski(a)m-works.net> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c index 26b506107a1a..865754737f5f 100644 --- a/drivers/mtd/nand/raw/arasan-nand-controller.c +++ b/drivers/mtd/nand/raw/arasan-nand-controller.c @@ -1478,8 +1478,15 @@ static int anfc_probe(struct platform_device *pdev) static void anfc_remove(struct platform_device *pdev) { + int i; struct arasan_nfc *nfc = platform_get_drvdata(pdev); + for (i = 0; i < nfc->ncs; i++) { + if (nfc->cs_array[i]) { + gpiod_put(nfc->cs_array[i]); + } + } + anfc_chips_cleanup(nfc); }

1 week, 5 days

1
0
0 0

[PATCH stable 6.1 5.15 5.10] bpf: Check validity of link->type in bpf_link_show_fdinfo()

by Shung-Hsi Yu

From: Hou Tao <houtao1(a)huawei.com> commit 8421d4c8762bd022cb491f2f0f7019ef51b4f0a7 upstream. If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed. Signed-off-by: Hou Tao <houtao1(a)huawei.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20241024013558.1135167-3-houtao@huaweicloud.com [ shung-hsi.yu: break up existing seq_printf() call since commit 68b04864ca42 ("bpf: Create links for BPF struct_ops maps.") is not present ] Signed-off-by: Shung-Hsi Yu <shung-hsi.yu(a)suse.com> --- kernel/bpf/syscall.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index f9906e5ad2e5..6455f80099cd 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -2816,16 +2816,21 @@ static void bpf_link_show_fdinfo(struct seq_file *m, struct file *filp) { const struct bpf_link *link = filp->private_data; const struct bpf_prog *prog = link->prog; + enum bpf_link_type type = link->type; char prog_tag[sizeof(prog->tag) * 2 + 1] = { }; + if (type < ARRAY_SIZE(bpf_link_type_strs) && bpf_link_type_strs[type]) { + seq_printf(m, "link_type:\t%s\n", bpf_link_type_strs[type]); + } else { + WARN_ONCE(1, "missing BPF_LINK_TYPE(...) for link type %u\n", type); + seq_printf(m, "link_type:\t<%u>\n", type); + } + seq_printf(m, "link_id:\t%u\n", link->id); + bin2hex(prog_tag, prog->tag, sizeof(prog->tag)); seq_printf(m, - "link_type:\t%s\n" - "link_id:\t%u\n" "prog_tag:\t%s\n" "prog_id:\t%u\n", - bpf_link_type_strs[link->type], - link->id, prog_tag, prog->aux->id); if (link->ops->show_fdinfo) -- 2.47.1

1 week, 6 days

2
1
0 0

Many Rx Errors since updating to kernel 6.12.6

by Mike Eddy

since updating from 6.12.5-100.fc40.x86_64 to 6.12.6-100.fc40.x86_64 I am getting many, many: kernel: r8169 0000:01:00.0 enp1s0: Rx ERROR. status = 352ac5ee and some: kernel: r8169 0000:01:00.0 enp1s0: NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 5376 ms kernel: r8169 0000:01:00.0: can't disable ASPM; OS doesn't have ASPM control Thanks! Mike Eddy

1 week, 6 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024