May 2025 - Linux-stable-mirror

[PATCH] parisc stable patch for kernel v6.12

by Helge Deller

Hi Greg, below is a backport for upstream patch fd87b7783802 ("net: Fix the devmem sock opts and msgs for parisc"). This upstream patch does not apply cleanly against v6.12, and backporting all intermediate changes are too big, so I created this trivial standalone patch instead. Can you please add the patc below to the stable queue for v6.12? Thanks! Helge --- From: Pranjal Shrivastava <praan(a)google.com> Date: Mon, 24 Mar 2025 07:42:27 +0000 Subject: [PATCH] net: Fix the devmem sock opts and msgs for parisc The devmem socket options and socket control message definitions introduced in the TCP devmem series[1] incorrectly continued the socket definitions for arch/parisc. The UAPI change seems safe as there are currently no drivers that declare support for devmem TCP RX via PP_FLAG_ALLOW_UNREADABLE_NETMEM. Hence, fixing this UAPI should be safe. Fix the devmem socket options and socket control message definitions to reflect the series followed by arch/parisc. [1] https://lore.kernel.org/lkml/20240910171458.219195-10-almasrymina@google.co… Patch modified for kernel 6.12 by Helge Deller. Fixes: 8f0b3cc9a4c10 ("tcp: RX path for devmem TCP") Signed-off-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: Helge Deller <deller(a)gmx.de> diff --git b/arch/parisc/include/uapi/asm/socket.h a/arch/parisc/include/uapi/asm/socket.h index 38fc0b188e08..96831c988606 100644 --- b/arch/parisc/include/uapi/asm/socket.h +++ a/arch/parisc/include/uapi/asm/socket.h @@ -132,11 +132,15 @@ #define SO_PASSPIDFD 0x404A #define SO_PEERPIDFD 0x404B -#define SO_DEVMEM_LINEAR 78 +#define SCM_TS_OPT_ID 0x404C + +#define SO_RCVPRIORITY 0x404D + +#define SO_DEVMEM_LINEAR 0x404E #define SCM_DEVMEM_LINEAR SO_DEVMEM_LINEAR -#define SO_DEVMEM_DMABUF 79 +#define SO_DEVMEM_DMABUF 0x404F #define SCM_DEVMEM_DMABUF SO_DEVMEM_DMABUF -#define SO_DEVMEM_DONTNEED 80 +#define SO_DEVMEM_DONTNEED 0x4050 #if !defined(__KERNEL__)

3 months, 3 weeks

1
0
0 0

[PATCH v3 0/2] iio: accel: fxls8962af: Fix temperature readings

by Sean Nyekjaer

Add the correct scale to get temperature in mili degree Celcius. Add sign component to temperature scan element. Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> --- Changes in v3: - Dropping define infavor of inline scale value - Added using constants from units.h - Tweaked commit msg to make it more assertive - Link to v2: https://lore.kernel.org/r/20250502-fxls-v2-0-e1af65f1aa6c@geanix.com Changes in v2: - Correct offset is applied before scaling component - Added sign component to temperature scan element - Link to v1: https://lore.kernel.org/r/20250501-fxls-v1-1-f54061a07099@geanix.com --- Sean Nyekjaer (2): iio: accel: fxls8962af: Fix temperature calculation iio: accel: fxls8962af: Fix temperature scan element sign drivers/iio/accel/fxls8962af-core.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- base-commit: 609bc31eca06c7408e6860d8b46311ebe45c1fef change-id: 20250501-fxls-307ef3d6d065 Best regards, -- Sean Nyekjaer <sean(a)geanix.com>

3 months, 3 weeks

2
4
0 0

[PATCH v2] video: screen_info: Relocate framebuffers behind PCI bridges

by Thomas Zimmermann

Apply bridge window offsets to screen_info framebuffers during relocation. Fixes invalid access to I/O memory. Resources behind a PCI bridge can be located at a certain offset in the kernel's I/O range. The framebuffer memory range stored in screen_info refers to the offset as seen during boot (essentialy 0). During boot up, the kernel may assign a different memory offset to the bridge device 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 resource. The result now matches the I/O-memory resource of the PCI graphics device. As before, we store away the information necessary to update the information in screen_info. 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. v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> 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+ --- drivers/video/screen_info_pci.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/video/screen_info_pci.c b/drivers/video/screen_info_pci.c index 6c5833517141..c46c75dc3fae 100644 --- a/drivers/video/screen_info_pci.c +++ b/drivers/video/screen_info_pci.c @@ -8,7 +8,7 @@ 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 struct pci_bus_region screen_info_lfb_region; 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_region.start) { if (__screen_info_relocation_is_valid(si, pr)) { /* * Only update base if we have an actual @@ -69,10 +69,21 @@ static void screen_info_fixup_lfb(struct pci_dev *pdev) for (i = 0; i < numres; ++i) { struct resource *r = &res[i]; + struct pci_bus_region bus_region = { + .start = r->start, + .end = r->end, + }; const struct resource *pr; if (!(r->flags & IORESOURCE_MEM)) continue; + + /* + * Translate the address to resource if the framebuffer + * is behind a PCI bridge. + */ + pcibios_bus_to_resource(pdev->bus, r, &bus_region); + pr = pci_find_resource(pdev, r); if (!pr) continue; @@ -85,7 +96,7 @@ static void screen_info_fixup_lfb(struct pci_dev *pdev) 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)); + memcpy(&screen_info_lfb_region, &bus_region, sizeof(screen_info_lfb_region)); } } DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16, -- 2.49.0

3 months, 3 weeks

2
3
0 0

[PATCH 2/5] rust: clean Rust 1.87.0's `clippy::ptr_eq` lints

by Miguel Ojeda

Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the `ptr_eq` lint, e.g.: error: use `core::ptr::eq` when comparing raw pointers --> rust/kernel/list.rs:438:12 | 438 | if self.first == item { | ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq = note: `-D clippy::ptr-eq` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]` Thus clean the few cases we have. This patch may not be actually needed by the time Rust 1.87.0 releases since a PR to relax the lint has been beta nominated [2] due to reports of being too eager (at least by default) [3]. Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14339 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2] Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- rust/kernel/alloc/kvec.rs | 2 +- rust/kernel/list.rs | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs index ae9d072741ce..cde911551327 100644 --- a/rust/kernel/alloc/kvec.rs +++ b/rust/kernel/alloc/kvec.rs @@ -743,7 +743,7 @@ fn into_raw_parts(self) -> (*mut T, NonNull<T>, usize, usize) { pub fn collect(self, flags: Flags) -> Vec<T, A> { let old_layout = self.layout; let (mut ptr, buf, len, mut cap) = self.into_raw_parts(); - let has_advanced = ptr != buf.as_ptr(); + let has_advanced = !core::ptr::eq(ptr, buf.as_ptr()); if has_advanced { // Copy the contents we have advanced to at the beginning of the buffer. diff --git a/rust/kernel/list.rs b/rust/kernel/list.rs index a335c3b1ff5e..c63cbeee3316 100644 --- a/rust/kernel/list.rs +++ b/rust/kernel/list.rs @@ -435,7 +435,7 @@ unsafe fn remove_internal_inner( // * If `item` was the only item in the list, then `prev == item`, and we just set // `item->next` to null, so this correctly sets `first` to null now that the list is // empty. - if self.first == item { + if core::ptr::eq(self.first, item) { // SAFETY: The `prev` pointer is the value that `item->prev` had when it was in this // list, so it must be valid. There is no race since `prev` is still in the list and we // still have exclusive access to the list. @@ -556,7 +556,7 @@ fn next(&mut self) -> Option<ArcBorrow<'a, T>> { let next = unsafe { (*current).next }; // INVARIANT: If `current` was the last element of the list, then this updates it to null. // Otherwise, we update it to the next element. - self.current = if next != self.stop { + self.current = if !core::ptr::eq(next, self.stop) { next } else { ptr::null_mut() @@ -726,7 +726,7 @@ impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> Cursor<'a, T, ID> { fn prev_ptr(&self) -> *mut ListLinksFields { let mut next = self.next; let first = self.list.first; - if next == first { + if core::ptr::eq(next, first) { // We are before the first element. return core::ptr::null_mut(); } @@ -788,7 +788,7 @@ pub fn move_next(&mut self) -> bool { // access the `next` field. let mut next = unsafe { (*self.next).next }; - if next == self.list.first { + if core::ptr::eq(next, self.list.first) { next = core::ptr::null_mut(); } @@ -802,7 +802,7 @@ pub fn move_next(&mut self) -> bool { /// If the cursor is before the first element, then this call does nothing. This call returns /// `true` if the cursor's position was changed. pub fn move_prev(&mut self) -> bool { - if self.next == self.list.first { + if core::ptr::eq(self.next, self.list.first) { return false; } @@ -822,7 +822,7 @@ fn insert_inner(&mut self, item: ListArc<T, ID>) -> *mut ListLinksFields { // * `ptr` is an element in the list or null. // * if `ptr` is null, then `self.list.first` is null so the list is empty. let item = unsafe { self.list.insert_inner(item, ptr) }; - if self.next == self.list.first { + if core::ptr::eq(self.next, self.list.first) { // INVARIANT: We just inserted `item`, so it's a member of list. self.list.first = item; } -- 2.49.0

3 months, 3 weeks

3
2
0 0

[PATCH for 6.1.y] LoongArch: Fix build error due to backport

by Huacai Chen

In 6.1 there is no pmdp_get() definition, so use *pmd directly, in order to avoid such build error due to a recently backport: arch/loongarch/mm/hugetlbpage.c: In function 'huge_pte_offset': arch/loongarch/mm/hugetlbpage.c:50:25: error: implicit declaration of function 'pmdp_get'; did you mean 'ptep_get'? [-Wimplicit-function-declaration] 50 | return pmd_none(pmdp_get(pmd)) ? NULL : (pte_t *) pmd; | ^~~~~~~~ | ptep_get Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/mm/hugetlbpage.c b/arch/loongarch/mm/hugetlbpage.c index cf3b8785a921..70b4a51885c2 100644 --- a/arch/loongarch/mm/hugetlbpage.c +++ b/arch/loongarch/mm/hugetlbpage.c @@ -47,7 +47,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, pmd = pmd_offset(pud, addr); } } - return pmd_none(pmdp_get(pmd)) ? NULL : (pte_t *) pmd; + return pmd_none(*pmd) ? NULL : (pte_t *) pmd; } /* -- 2.47.1

3 months, 3 weeks

3
2
0 0

[PATCH 6.1] smb: client: fix double free of TCP_Server_Info::hostname

by Pavel Paklov

From: Pavel Paklov <pavel.paklov(a)cyberprotect.ru> From: Paulo Alcantara <pc(a)manguebit.com> commit fa2f9906a7b333ba757a7dbae0713d8a5396186e upstream When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Fixes: 7be3248f3139 ("cifs: To match file servers, make sure the server hostname matches") Reported-by: Jay Shin <jaeshin(a)redhat.com> Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Pavel Paklov <pavel.paklov(a)cyberprotect.ru> --- Backport fix for CVE-2025-21673 fs/smb/client/connect.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c index 01ce81f77e89..2b0657fe2a3f 100644 --- a/fs/smb/client/connect.c +++ b/fs/smb/client/connect.c @@ -1066,6 +1066,7 @@ static void clean_demultiplex_info(struct TCP_Server_Info *server) kfree(server->origin_fullpath); kfree(server->leaf_fullpath); #endif + kfree(server->hostname); kfree(server); length = atomic_dec_return(&tcpSesAllocCount); @@ -1688,8 +1689,6 @@ cifs_put_tcp_session(struct TCP_Server_Info *server, int from_reconnect) kfree_sensitive(server->session_key.response); server->session_key.response = NULL; server->session_key.len = 0; - kfree(server->hostname); - server->hostname = NULL; task = xchg(&server->tsk, NULL); if (task) -- 2.43.0

3 months, 3 weeks

2
1
0 0

[PATCH 6.12.y] bpf: Fix BPF_INTERNAL namespace import

by Xi Ruoyao

The commit cdd30ebb1b9f ("module: Convert symbol namespace to string literal") makes the grammar of MODULE_IMPORT_NS and EXPORT_SYMBOL_NS different between the stable branches and the mainline. But when the commit 955f9ede52b8 ("bpf: Add namespace to BPF internal symbols") was backported from mainline, only EXPORT_SYMBOL_NS instances are adapted, leaving the MODULE_IMPORT_NS instance with the "new" grammar and causing the module fails to build: ERROR: modpost: module bpf_preload uses symbol bpf_link_get_from_fd from namespace BPF_INTERNAL, but does not import it. ERROR: modpost: module bpf_preload uses symbol kern_sys_bpf from namespace BPF_INTERNAL, but does not import it. Reported-by: Mingcong Bai <jeffbai(a)aosc.io> Reported-by: Alex Davis <alex47794(a)gmail.com> Closes: https://lore.kernel.org/all/CADiockBKBQTVqjA5G+RJ9LBwnEnZ8o0odYnL=LBZ_7QN=_… Fixes: 955f9ede52b8 ("bpf: Add namespace to BPF internal symbols") Signed-off-by: Xi Ruoyao <xry111(a)xry111.site> --- kernel/bpf/preload/bpf_preload_kern.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/preload/bpf_preload_kern.c b/kernel/bpf/preload/bpf_preload_kern.c index 56a81df7a9d7..fdad0eb308fe 100644 --- a/kernel/bpf/preload/bpf_preload_kern.c +++ b/kernel/bpf/preload/bpf_preload_kern.c @@ -89,5 +89,5 @@ static void __exit fini(void) } late_initcall(load); module_exit(fini); -MODULE_IMPORT_NS("BPF_INTERNAL"); +MODULE_IMPORT_NS(BPF_INTERNAL); MODULE_LICENSE("GPL"); -- 2.49.0

3 months, 3 weeks

3
2
0 0

Please apply to v6.14.x commit 6eab70345799 ("ASoC: soc-core: Stop using of_property_read_bool() for non-boolean properties")

by LEROY Christophe

Hi, Could you please apply commit 6eab70345799 ("ASoC: soc-core: Stop using of_property_read_bool() for non-boolean properties") to v6.14.x in order to silence warnings introduced in v6.14 by commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties") Thanks Christophe

3 months, 3 weeks

3
4
0 0

[GIT PULL] bcachefs fixes for 6.14.y

by Kent Overstreet

The following changes since commit 02a22be3c0003af08df510cba3d79d00c6495b74: bcachefs: bch2_ioctl_subvolume_destroy() fixes (2025-04-03 16:13:53 -0400) are available in the Git repository at: git://evilpiepirate.org/bcachefs.git tags/bcachefs-for-6.14-2025-05-02 for you to fetch changes up to 52b17bca7b20663e5df6dbfc24cc2030259b64b6: bcachefs: Remove incorrect __counted_by annotation (2025-05-02 21:09:51 -0400) ---------------------------------------------------------------- bcachefs fixes for 6.15 remove incorrect counted_by annotation, fixing FORTIFY_SOURCE crashes that have been hitting arch users ---------------------------------------------------------------- Alan Huang (1): bcachefs: Remove incorrect __counted_by annotation fs/bcachefs/xattr_format.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)

3 months, 3 weeks

2
6
0 0

[6.12.y] WARNING: CPU: 0 PID: 681 at block/blk-mq-cpumap.c:90 blk_mq_map_hw_queues+0xcf/0xe0

by Wang Yugui

Hi, I noticed a WARNING in recent 6.12.y kernel. This WARNING happen on 6.12.26/6.12.25, but not happen on 6.12.20. More bisect job need to be done, but reporti it firstly. [ 13.288365] ------------[ cut here ]------------ [ 13.288366] WARNING: CPU: 0 PID: 681 at block/blk-mq-cpumap.c:90 blk_mq_map_hw_queues+0xcf/0xe0 void blk_mq_map_hw_queues(struct blk_mq_queue_map *qmap, struct device *dev, unsigned int offset) { ... ... fallback: L90： WARN_ON_ONCE(qmap->nr_queues > 1); blk_mq_clear_mq_map(qmap); } [ 13.288373] Modules linked in: ahci(+) mlxfw libahci pci_hyperv_intf bnx2x(+) i40e(+) mpi3mr(+) psample bnxt_en(+) libata mgag200(+) tls megaraid_sas(+) crc32c_intel scsi_transport_sas mdio libie i2c_algo_bit wmi dm_mirror dm_region_hash dm_log dm_mod [ 13.288386] CPU: 0 UID: 0 PID: 681 Comm: kworker/0:2 Not tainted 6.12.26-1.el7.x86_64 #1 [ 13.288388] Hardware name: Dell Inc. PowerEdge T640/0TWW5Y, BIOS 2.22.1 09/12/2024 [ 13.288390] Workqueue: events work_for_cpu_fn [ 13.288394] RIP: 0010:blk_mq_map_hw_queues+0xcf/0xe0 [ 13.288396] Code: 8b 35 85 e4 9a 02 48 63 d0 48 c7 c7 e0 e5 78 94 e8 26 0b 07 00 39 05 70 e4 9a 02 77 d3 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc <0f> 0b eb d2 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90 [ 13.288398] RSP: 0018:ffffc0e11b83bd38 EFLAGS: 00010212 [ 13.288400] RAX: 0000000000000000 RBX: ffffa0804ad58000 RCX: 0000000000000050 [ 13.288402] RDX: 0000000000000050 RSI: ffffa07f8f24d0c8 RDI: ffffa0804ad580e8 [ 13.288403] RBP: ffffa0804ad580e0 R08: 000000000000004f R09: 0000000000000000 [ 13.288404] R10: ffffc0e11b83bd78 R11: ffffa07f9039da00 R12: 0000000000000000 [ 13.288405] R13: 0000000000000001 R14: ffffa0804ad580e8 R15: 0000000000000000 [ 13.288406] FS: 0000000000000000(0000) GS:ffffa0dd3fe00000(0000) knlGS:0000000000000000 [ 13.288407] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 13.288408] CR2: 00007f1f3226ba20 CR3: 00000002f9780005 CR4: 00000000007706f0 [ 13.288409] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 13.288410] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 13.288411] PKRU: 55555554 [ 13.288412] Call Trace: [ 13.288413] <TASK> [ 13.288415] megasas_map_queues+0x49/0x90 [megaraid_sas] [ 13.288431] blk_mq_alloc_tag_set+0x150/0x3b0 [ 13.288436] scsi_add_host_with_dma+0xd0/0x350 [ 13.288440] megasas_io_attach+0x15c/0x220 [megaraid_sas] [ 13.288456] megasas_probe_one+0x1cb/0x570 [megaraid_sas] [ 13.288468] local_pci_probe+0x47/0xa0 [ 13.288474] work_for_cpu_fn+0x17/0x30 [ 13.288475] process_one_work+0x179/0x3a0 [ 13.288480] worker_thread+0x24b/0x350 [ 13.288483] ? __pfx_worker_thread+0x10/0x10 [ 13.288485] kthread+0xde/0x110 [ 13.288489] ? __pfx_kthread+0x10/0x10 [ 13.288491] ret_from_fork+0x31/0x50 [ 13.288494] ? __pfx_kthread+0x10/0x10 [ 13.288496] ret_from_fork_asm+0x1a/0x30 [ 13.288502] </TASK> [ 13.288502] ---[ end trace 0000000000000000 ]--- Best Regards Wang Yugui (wangyugui(a)e16-tech.com) 2025/05/03

3 months, 3 weeks

6
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025