added support for Sony Vaio E-Series bluetooth #25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
November 10, 2012 12:12
foxconn hon/hai 0489:e027
foxconn hon/hai 0489:e027
wrobelda
referenced
this pull request
in wrobelda/linux-sunxi
Nov 10, 2012
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 linux-sunxi#1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] linux-sunxi#2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f linux-sunxi#3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 linux-sunxi#4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] linux-sunxi#5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] linux-sunxi#6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 linux-sunxi#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 linux-sunxi#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 linux-sunxi#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f linux-sunxi#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e linux-sunxi#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f linux-sunxi#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad linux-sunxi#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 linux-sunxi#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a linux-sunxi#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 linux-sunxi#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b linux-sunxi#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 linux-sunxi#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c linux-sunxi#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 linux-sunxi#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 linux-sunxi#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] linux-sunxi#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] linux-sunxi#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 linux-sunxi#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 linux-sunxi#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
I don't do github pull requests. Nobody does. They don't work. Use the normal kernel pull models, with emails and real pull requests. And On Sat, Nov 10, 2012 at 12:16 PM, Paolo Stivanin
|
amery
referenced
this pull request
in amery/linux-sunxi
Nov 12, 2012
LogFS does not use a specialized area to maintain the inodes. The inodes information is kept in a specialized file called inode file. Similarly, the segment information is kept in a segment file. Since the segment file also has an inode which is kept in the inode file, the inode for segment file must be evicted before the inode for inode file. The change fixes the following BUG during unmount Pid: 2057, comm: umount Not tainted 3.5.0-rc6+ linux-sunxi#25 Bochs Bochs RIP: 0010:[<ffffffffa005c5f2>] [<ffffffffa005c5f2>] move_page_to_btree+0x32/0x1f0 [logfs] Process umount (pid: 2057, threadinfo ...) Call Trace: [<ffffffff8112adca>] ? find_get_pages+0x2a/0x180 [<ffffffffa00549f5>] logfs_invalidatepage+0x85/0x90 [logfs] [<ffffffff81136c51>] truncate_inode_page+0xb1/0xd0 [<ffffffff81136dcf>] truncate_inode_pages_range+0x15f/0x490 [<ffffffff81558549>] ? printk+0x78/0x7a [<ffffffff81137185>] truncate_inode_pages+0x15/0x20 [<ffffffffa005b7fc>] logfs_evict_inode+0x6c/0x190 [logfs] [<ffffffff8155c75b>] ? _raw_spin_unlock+0x2b/0x40 [<ffffffff8119e3d7>] evict+0xa7/0x1b0 [<ffffffff8119ea6e>] dispose_list+0x3e/0x60 [<ffffffff8119f1c4>] evict_inodes+0xf4/0x110 [<ffffffff81185b53>] generic_shutdown_super+0x53/0xf0 [<ffffffffa005d8f2>] logfs_kill_sb+0x52/0xf0 [logfs] [<ffffffff81185ec5>] deactivate_locked_super+0x45/0x80 [<ffffffff81186a4a>] deactivate_super+0x4a/0x70 [<ffffffff811a228e>] mntput_no_expire+0xde/0x140 [<ffffffff811a30ff>] sys_umount+0x6f/0x3a0 [<ffffffff8155d8e9>] system_call_fastpath+0x16/0x1b ---[ end trace 45f7752082cefafd ]--- Signed-off-by: Prasad Joshi <[email protected]>
amery
referenced
this pull request
in amery/linux-sunxi
Nov 12, 2012
…d reasons
We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:
PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14"
#0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
linux-sunxi#1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
linux-sunxi#2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
linux-sunxi#3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
linux-sunxi#4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
linux-sunxi#5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
linux-sunxi#6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
linux-sunxi#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
linux-sunxi#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
linux-sunxi#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
linux-sunxi#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
linux-sunxi#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
linux-sunxi#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
linux-sunxi#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
linux-sunxi#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
linux-sunxi#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
linux-sunxi#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
linux-sunxi#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
linux-sunxi#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
linux-sunxi#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
linux-sunxi#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
linux-sunxi#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
linux-sunxi#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
linux-sunxi#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
linux-sunxi#24 [ffff8810343bfee8] kthread at ffffffff8108dd96
linux-sunxi#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca
rpciod is trying to allocate memory for a new socket to talk to the
server. The VM ends up calling ->releasepage to get more memory, and it
tries to do a blocking commit. That commit can't succeed however without
a connected socket, so we deadlock.
Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
socket allocation, and having nfs_release_page check for that flag when
deciding whether to do a commit call. Also, set PF_FSTRANS
unconditionally in rpc_async_schedule since that function can also do
allocations sometimes.
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected]
amery
referenced
this pull request
in amery/linux-sunxi
Nov 12, 2012
This patch fixes stmmac_pltfr_remove function, which is broken because, it is accessing plat variable via freed memory priv pointer which gets freed by free_netdev called from stmmac_dvr_remove. In short this patch caches the plat pointer in local variable before calling stmmac_dvr_remove to prevent code accessing freed memory. Without this patch any attempt to remove the stmmac device will fail as below: Unregistering eth 0 ... Unable to handle kernel paging request at virtual address 6b6b6bab pgd = de5dc000 [6b6b6bab] *pgd=00000000 Internal error: Oops: 5 [linux-sunxi#1] PREEMPT SMP Modules linked in: cdev(O+) CPU: 0 Tainted: G O (3.3.1_stm24_0210-b2000+ linux-sunxi#25) PC is at stmmac_pltfr_remove+0x2c/0xa0 LR is at stmmac_pltfr_remove+0x28/0xa0 pc : [<c01b8908>] lr : [<c01b8904>] psr: 60000013 sp : def6be78 ip : de6c5a00 fp : 00000000 r10: 00000028 r9 : c082d81d r8 : 00000001 r7 : de65a600 r6 : df81b240 r5 : c0413fd8 r4 : 00000000 r3 : 6b6b6b6b r2 : def6be6c r1 : c0355e2b r0 : 00000020 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 5e5dc04a DAC: 00000015 Process insmod (pid: 738, stack limit = 0xdef6a2f0) Stack: (0xdef6be78 to 0xdef6c000) be60: c0413fe0 c0403658 be80: c0400bb0 c019270c c01926f8 c0191478 00000000 c0414014 c0413fe0 c01914d8 bea0: 00000000 c0413fe0 df8045d0 c019109c c0413fe0 c0400bf0 c0413fd8 c018f04c bec0: 00000000 bf000000 c0413fd8 c01929a0 c0413fd8 bf000000 00000000 c0192bfc bee0: bf00009c bf000014 def6a000 c000859c 00000000 00000001 bf00009c bf00009c bf00: 00000001 bf00009c 00000001 bf0000e4 de65a600 00000001 c082d81d c0058cd0 bf20: bf0000a8 c004fbd8 c0056414 c082d815 c02aea20 bf0001f0 00b0b008 e0846208 bf40: c03ec8a0 e0846000 0000db0d e0850604 e08504de e0853a24 00000204 000002d4 bf60: 00000000 00000000 0000001c 0000001d 00000009 00000000 00000006 00000000 bf80: 00000003 f63d4e2e 0000db0d bef02ed8 00000080 c000d2e8 def6a000 00000000 bfa0: 00000000 c000d140 f63d4e2e 0000db0d 00b0b018 0000db0d 00b0b008 b6f4f298 bfc0: f63d4e2e 0000db0d bef02ed8 00000080 00000003 00000000 00010000 00000000 bfe0: 00b0b008 bef02c64 00008d20 b6ef3784 60000010 00b0b018 5a5a5a5a 5a5a5a5a [<c01b8908>] (stmmac_pltfr_remove+0x2c/0xa0) from [<c019270c>] (platform_drv_remove+0x14/0x18) [<c019270c>] (platform_drv_remove+0x14/0x18) from [<c0191478>] (__device_release_driver+0x64/0xa4) [<c0191478>] (__device_release_driver+0x64/0xa4) from [<c01914d8>] (device_release_driver+0x20/0x2c) [<c01914d8>] (device_release_driver+0x20/0x2c) from [<c019109c>] (bus_remove_device+0xcc/0xdc) [<c019109c>] (bus_remove_device+0xcc/0xdc) from [<c018f04c>] (device_del+0x104/0x160) [<c018f04c>] (device_del+0x104/0x160) from [<c01929a0>] (platform_device_del+0x18/0x58) [<c01929a0>] (platform_device_del+0x18/0x58) from [<c0192bfc>] (platform_device_unregister+0xc/0x18) [<c0192bfc>] (platform_device_unregister+0xc/0x18) from [<bf000014>] (r_init+0x14/0x2c [cdev]) [<bf000014>] (r_init+0x14/0x2c [cdev]) from [<c000859c>] (do_one_initcall+0x90/0x160) [<c000859c>] (do_one_initcall+0x90/0x160) from [<c0058cd0>] (sys_init_module+0x15c4/0x1794) [<c0058cd0>] (sys_init_module+0x15c4/0x1794) from [<c000d140>] (ret_fast_syscall+0x0/0x30) Code: e1a04000 e59f0070 eb039b65 e59636e4 (e5933040) Signed-off-by: Srinivas Kandagatla <[email protected]> Signed-off-by: David S. Miller <[email protected]>
jadonk
pushed a commit
to jadonk/linux
that referenced
this pull request
Nov 13, 2012
Printing the "start_ip" for every secondary cpu is very noisy on a large
system - and doesn't add any value. Drop this message.
Console log before:
Booting Node 0, Processors #1
smpboot cpu 1: start_ip = 96000
#2
smpboot cpu 2: start_ip = 96000
#3
smpboot cpu 3: start_ip = 96000
#4
smpboot cpu 4: start_ip = 96000
...
torvalds#31
smpboot cpu 31: start_ip = 96000
Brought up 32 CPUs
Console log after:
Booting Node 0, Processors #1 #2 #3 #4 #5 torvalds#6 torvalds#7 Ok.
Booting Node 1, Processors torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 Ok.
Booting Node 0, Processors torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 Ok.
Booting Node 1, Processors torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31
Brought up 32 CPUs
Acked-by: Borislav Petkov <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
koenkooi
pushed a commit
to koenkooi/linux
that referenced
this pull request
Nov 14, 2012
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
kees
pushed a commit
to kees/linux
that referenced
this pull request
Nov 16, 2012
…d reasons BugLink: http://bugs.launchpad.net/bugs/1035435 commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] torvalds#6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 torvalds#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 torvalds#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 torvalds#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Herton Ronaldo Krzesinski <[email protected]>
koenkooi
pushed a commit
to koenkooi/linux
that referenced
this pull request
Nov 21, 2012
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
fabiokung
pushed a commit
to fabiokung/linux
that referenced
this pull request
Dec 8, 2012
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] torvalds#6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 torvalds#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 torvalds#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 torvalds#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Dec 12, 2012
… built as a module [ 12.761956] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 12.762016] IP: [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.762060] PGD 1fec74067 PUD 1fee5b067 PMD 0 [ 12.762127] Oops: 0000 [#1] SMP [ 12.762177] Modules linked in: hid_generic crc32c_intel usbhid hid firewire_ohci(+) e1000e(+) firewire_core crc_itu_t xhci_hcd(+) thermal(+) fan thermal_sys hwmon [ 12.762423] CPU 1 [ 12.762443] Pid: 187, comm: modprobe Tainted: G A 3.7.0-thermal-module+ #25 /DH77DF [ 12.762496] RIP: 0010:[<ffffffffa0005277>] [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.762682] RSP: 0018:ffff8801fe7ddc18 EFLAGS: 00010282 [ 12.762704] RAX: 0000000000000000 RBX: ffff8801ff3e9c00 RCX: ffff8801fdc39800 [ 12.762728] RDX: ffff8801fe7ddc24 RSI: 0000000000000001 RDI: ffff8801ff3e9c00 [ 12.762764] RBP: ffff8801fe7ddc48 R08: 0000000004000000 R09: ffffffffa001f568 [ 12.762797] R10: ffffffff81363083 R11: 0000000000000001 R12: 0000000000000001 [ 12.762832] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8801fde73e68 [ 12.762866] FS: 00007f5548516700(0000) GS:ffff88021f240000(0000) knlGS:0000000000000000 [ 12.762912] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 12.762946] CR2: 0000000000000018 CR3: 00000001fefe2000 CR4: 00000000001407e0 [ 12.762979] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 12.763014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 12.763048] Process modprobe (pid: 187, threadinfo ffff8801fe7dc000, task ffff8801fe5bdb40) [ 12.763095] Stack: [ 12.763122] 0000000000019640 00000000fdc39800 ffff8801fe7ddc48 ffff8801ff3e9c00 [ 12.763225] 0000000000000002 0000000000000000 ffff8801fe7ddc78 ffffffffa00053e7 [ 12.763338] ffff8801ff3e9c00 0000000000006c98 ffffffffa0007480 ffff8801ff3e9c00 [ 12.763440] Call Trace: [ 12.763470] [<ffffffffa00053e7>] thermal_zone_device_update+0x77/0xa0 [thermal_sys] [ 12.763515] [<ffffffffa0006d38>] thermal_zone_device_register+0x788/0xa88 [thermal_sys] [ 12.763562] [<ffffffffa001f394>] acpi_thermal_add+0x360/0x4c8 [thermal] [ 12.763598] [<ffffffff8133902a>] acpi_device_probe+0x50/0x190 [ 12.763632] [<ffffffff811bd793>] ? sysfs_create_link+0x13/0x20 [ 12.763666] [<ffffffff813cc41b>] driver_probe_device+0x7b/0x240 [ 12.763699] [<ffffffff813cc68b>] __driver_attach+0xab/0xb0 [ 12.763732] [<ffffffff813cc5e0>] ? driver_probe_device+0x240/0x240 [ 12.763766] [<ffffffff813ca836>] bus_for_each_dev+0x56/0x90 [ 12.763799] [<ffffffff813cbf4e>] driver_attach+0x1e/0x20 [ 12.763831] [<ffffffff813cbac0>] bus_add_driver+0x190/0x290 [ 12.763864] [<ffffffffa0022000>] ? 0xffffffffa0021fff [ 12.763896] [<ffffffff813ccbea>] driver_register+0x7a/0x160 [ 12.763928] [<ffffffffa0022000>] ? 0xffffffffa0021fff [ 12.763960] [<ffffffff813399fb>] acpi_bus_register_driver+0x43/0x45 [ 12.763995] [<ffffffffa002203a>] acpi_thermal_init+0x3a/0x42 [thermal] [ 12.764029] [<ffffffff8100207f>] do_one_initcall+0x3f/0x170 [ 12.764063] [<ffffffff810b1a5f>] sys_init_module+0x8f/0x200 [ 12.764097] [<ffffffff815ff259>] system_call_fastpath+0x16/0x1b [ 12.764129] Code: 48 8b 87 c8 02 00 00 41 89 f4 48 8d 55 dc ff 50 28 44 8b 6d dc 41 8d 45 fe 83 f8 01 76 5e 48 8b 83 d8 02 00 00 44 89 e6 48 89 df <ff> 50 18 4c 8d a3 10 03 00 00 4c 89 e7 e8 87 f1 5e e1 8b 83 bc [ 12.765164] RIP [<ffffffffa0005277>] handle_thermal_trip+0x47/0x130 [thermal_sys] [ 12.765223] RSP <ffff8801fe7ddc18> [ 12.765252] CR2: 0000000000000018 [ 12.765284] ---[ end trace 7723294cdfb00d2a ]--- This is because thermal_zone_device_update() is invoked before any thermal governors being registered. Signed-off-by: Zhang Rui <[email protected]>
vineetgarc
added a commit
to foss-for-synopsys-dwc-arc-processors/linux
that referenced
this pull request
Dec 31, 2012
…mon SMP Moved the ISS specific Kconfig option (ARC_HAS_SMP_EXTN_MODEL) from ARC Kconfig to plat-arcfpga (also renamed to ISS_SMP_EXTN). ARC_HAS_IPI needs to be selected by platforms which can support the Inter-Processor-Interrupts. This in turn enables SMP in arch/arc/Kconfig Signed-off-by: Vineet Gupta <[email protected]>
cianmcgovern
pushed a commit
to cianmcgovern/linux
that referenced
this pull request
Mar 10, 2013
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] torvalds#6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 torvalds#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 torvalds#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 torvalds#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
dormando
pushed a commit
to fastly/linux
that referenced
this pull request
Mar 30, 2013
…d reasons commit 5cf02d0 upstream. We've had some reports of a deadlock where rpciod ends up with a stack trace like this: PID: 2507 TASK: ffff88103691ab40 CPU: 14 COMMAND: "rpciod/14" #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9 #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs] #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8 #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs] #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs] #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670 torvalds#7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271 torvalds#8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638 torvalds#9 [ffff8810343bf818] shrink_zone at ffffffff8112788f torvalds#10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e torvalds#11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f torvalds#12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad torvalds#13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942 torvalds#14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a torvalds#15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9 torvalds#16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b torvalds#17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808 torvalds#18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c torvalds#19 [ffff8810343bfce8] inet_create at ffffffff81483ba6 torvalds#20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7 torvalds#21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc] torvalds#22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc] torvalds#23 [ffff8810343bfe38] worker_thread at ffffffff810887d0 torvalds#24 [ffff8810343bfee8] kthread at ffffffff8108dd96 torvalds#25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca rpciod is trying to allocate memory for a new socket to talk to the server. The VM ends up calling ->releasepage to get more memory, and it tries to do a blocking commit. That commit can't succeed however without a connected socket, so we deadlock. Fix this by setting PF_FSTRANS on the workqueue task prior to doing the socket allocation, and having nfs_release_page check for that flag when deciding whether to do a commit call. Also, set PF_FSTRANS unconditionally in rpc_async_schedule since that function can also do allocations sometimes. Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
rjwysocki
pushed a commit
to rjwysocki/linux-pm
that referenced
this pull request
Apr 4, 2013
Check for the presence of the '/cpus' OF node before dereferencing it blindly: [ 4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c [ 4.181793] pgd = c0004000 [ 4.181823] [0000001c] *pgd=00000000 [ 4.181823] Internal error: Oops: 5 [#1] SMP ARM [ 4.181823] Modules linked in: [ 4.181823] CPU: 1 Tainted: G W (3.8.0-15-generic torvalds#25~hbankD) [ 4.181854] PC is at of_get_next_child+0x64/0x70 [ 4.181854] LR is at of_get_next_child+0x24/0x70 [ 4.181854] pc : [<c04fda18>] lr : [<c04fd9d8>] psr: 60000113 [ 4.181854] sp : ed891ec0 ip : ed891ec0 fp : ed891ed4 [ 4.181884] r10: c04dafd0 r9 : c098690c r8 : c0936208 [ 4.181884] r7 : ed890000 r6 : c0a63d00 r5 : 00000000 r4 : 00000000 [ 4.181884] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : c0b2acc8 [ 4.181884] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 4.181884] Control: 10c5387d Table: adcb804a DAC: 00000015 [ 4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238) [ 4.181915] Stack: (0xed891ec0 to 0xed892000) [ 4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70 [ 4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc [ 4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914 [ 4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208 [ 4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007 [ 4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000 [ 4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000 [ 4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000 [ 4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) [ 4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0) [ 4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c) [ 4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4) [ 4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20) [ 4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c) [ 4.182128] ---[ end trace 634903a22e8609cb ]--- [ 4.182189] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 4.182189] [ 4.642395] CPU0: stopping [rjw: Changelog] Signed-off-by: Paolo Pisati <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
tom3q
pushed a commit
to tom3q/linux
that referenced
this pull request
Apr 21, 2013
ERROR: space required before the open parenthesis '('
torvalds#25: FILE: ipc/sem.c:1101:
+ if(semnum < 0 || semnum >= nsems) {
total: 1 errors, 0 warnings, 12 lines checked
./patches/ipcsem-do-not-hold-ipc-lock-more-than-necessary-fix.patch has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Sasha Levin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
tom3q
pushed a commit
to tom3q/linux
that referenced
this pull request
Apr 28, 2013
ERROR: space required before the open parenthesis '('
torvalds#25: FILE: ipc/sem.c:1101:
+ if(semnum < 0 || semnum >= nsems) {
total: 1 errors, 0 warnings, 12 lines checked
./patches/ipcsem-do-not-hold-ipc-lock-more-than-necessary-fix.patch has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Sasha Levin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Jul 10, 2013
Several people reported the warning: "kernel BUG at kernel/timer.c:729!" and the stack trace is: #7 [ffff880214d25c10] mod_timer+501 at ffffffff8106d905 #8 [ffff880214d25c50] br_multicast_del_pg.isra.20+261 at ffffffffa0731d25 [bridge] #9 [ffff880214d25c80] br_multicast_disable_port+88 at ffffffffa0732948 [bridge] #10 [ffff880214d25cb0] br_stp_disable_port+154 at ffffffffa072bcca [bridge] #11 [ffff880214d25ce8] br_device_event+520 at ffffffffa072a4e8 [bridge] #12 [ffff880214d25d18] notifier_call_chain+76 at ffffffff8164aafc #13 [ffff880214d25d50] raw_notifier_call_chain+22 at ffffffff810858f6 #14 [ffff880214d25d60] call_netdevice_notifiers+45 at ffffffff81536aad #15 [ffff880214d25d80] dev_close_many+183 at ffffffff81536d17 #16 [ffff880214d25dc0] rollback_registered_many+168 at ffffffff81537f68 #17 [ffff880214d25de8] rollback_registered+49 at ffffffff81538101 #18 [ffff880214d25e10] unregister_netdevice_queue+72 at ffffffff815390d8 #19 [ffff880214d25e30] __tun_detach+272 at ffffffffa074c2f0 [tun] #20 [ffff880214d25e88] tun_chr_close+45 at ffffffffa074c4bd [tun] #21 [ffff880214d25ea8] __fput+225 at ffffffff8119b1f1 #22 [ffff880214d25ef0] ____fput+14 at ffffffff8119b3fe #23 [ffff880214d25f00] task_work_run+159 at ffffffff8107cf7f #24 [ffff880214d25f30] do_notify_resume+97 at ffffffff810139e1 #25 [ffff880214d25f50] int_signal+18 at ffffffff8164f292 this is due to I forgot to check if mp->timer is armed in br_multicast_del_pg(). This bug is introduced by commit 9f00b2e (bridge: only expire the mdb entry when query is received). Same for __br_mdb_del(). Tested-by: poma <[email protected]> Reported-by: LiYonghua <[email protected]> Reported-by: Robert Hancock <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Stephen Hemminger <[email protected]> Cc: "David S. Miller" <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 OK [ 2.489005] smpboot: Booting Node 4, Processors: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 OK [ 3.093005] smpboot: Booting Node 5, Processors: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 OK [ 3.698005] smpboot: Booting Node 6, Processors: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 OK [ 4.304005] smpboot: Booting Node 7, Processors: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <[email protected]> Cc: Libin <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Oct 14, 2013
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Nov 22, 2013
Commit 7cb2ef5 ("mm: fix aio performance regression for database caused by THP") can cause dereference of a dangling pointer if split_huge_page runs during PageHuge() if there are updates to the tail_page->private field. Also it is repeating compound_head twice for hugetlbfs and it is running compound_head+compound_trans_head for THP when a single one is needed in both cases. The new code within the PageSlab() check doesn't need to verify that the THP page size is never bigger than the smallest hugetlbfs page size, to avoid memory corruption. A longstanding theoretical race condition was found while fixing the above (see the change right after the skip_unlock label, that is relevant for the compound_lock path too). By re-establishing the _mapcount tail refcounting for all compound pages, this also fixes the below problem: echo 0 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages BUG: Bad page state in process bash pfn:59a01 page:ffffea000139b038 count:0 mapcount:10 mapping: (null) index:0x0 page flags: 0x1c00000000008000(tail) Modules linked in: CPU: 6 PID: 2018 Comm: bash Not tainted 3.12.0+ #25 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x55/0x76 bad_page+0xd5/0x130 free_pages_prepare+0x213/0x280 __free_pages+0x36/0x80 update_and_free_page+0xc1/0xd0 free_pool_huge_page+0xc2/0xe0 set_max_huge_pages.part.58+0x14c/0x220 nr_hugepages_store_common.isra.60+0xd0/0xf0 nr_hugepages_store+0x13/0x20 kobj_attr_store+0xf/0x20 sysfs_write_file+0x189/0x1e0 vfs_write+0xc5/0x1f0 SyS_write+0x55/0xb0 system_call_fastpath+0x16/0x1b Signed-off-by: Khalid Aziz <[email protected]> Signed-off-by: Andrea Arcangeli <[email protected]> Tested-by: Khalid Aziz <[email protected]> Cc: Pravin Shelar <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Ben Hutchings <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
swarren
pushed a commit
to swarren/linux-tegra
that referenced
this pull request
Dec 12, 2013
WARNING: please, no space before tabs torvalds#25: FILE: kernel/params.c:230: +#define STANDARD_PARAM_DEF(name, type, format, strtolfn) ^I^I\$ total: 0 errors, 1 warnings, 39 lines checked ./patches/kernel-paramsc-improve-standard-definitions.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Felipe Contreras <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 14, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 17, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Signed-off-by: Tony Ambardar <[email protected]>
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Aug 19, 2025
If we hit an error path in GEM obj creation before msm_gem_new_handle()
updates obj->resv to point to the gpuvm resv object, then obj->resv
still points to &obj->_resv. In this case we don't want to decrement
the refcount of the object being freed (since the refcnt is already
zero). This fixes the following splat:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 9 PID: 7013 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_da>
qcom_pil_info i2c_hid drm_kms_helper qcom_common qcom_q6v5 phy_snps_eusb2 qcom_geni_serial drm qcom_sysmon pinctrl_s>
CPU: 9 UID: 1000 PID: 7013 Comm: deqp-vk Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xf4/0x148
lr : refcount_warn_saturate+0xf4/0x148
sp : ffff8000a2073920
x29: ffff8000a2073920 x28: 0000000000000010 x27: 0000000000000010
x26: 0000000000000042 x25: ffff000810e09800 x24: 0000000000000010
x23: ffff8000a2073b94 x22: ffff000ddb22de00 x21: ffff000ddb22dc00
x20: ffff000ddb22ddf8 x19: ffff0008024934e0 x18: 000000000000000a
x17: 0000000000000000 x16: ffff9f8c67d77340 x15: 0000000000000000
x14: 00000000ffffffff x13: 2e656572662d7265 x12: 7466612d65737520
x11: 3b776f6c66726564 x10: 00000000ffff7fff x9 : ffff9f8c67506c70
x8 : ffff9f8c69fa26f0 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
x5 : ffff000f53e14548 x4 : ffff6082ea2b2000 x3 : ffff0008b86ab080
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008b86ab080
Call trace:
refcount_warn_saturate+0xf4/0x148 (P)
msm_gem_free_object+0x248/0x260 [msm]
drm_gem_object_free+0x24/0x40 [drm]
msm_gem_new+0x1c4/0x1e0 [msm]
msm_gem_new_handle+0x3c/0x1a0 [msm]
msm_ioctl_gem_new+0x38/0x70 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 3698694
hardirqs last enabled at (3698693): [<ffff9f8c675021dc>] __up_console_sem+0x74/0x90
hardirqs last disabled at (3698694): [<ffff9f8c68ce8164>] el1_dbg+0x24/0x90
softirqs last enabled at (3697578): [<ffff9f8c6744ec5c>] handle_softirqs+0x454/0x4b0
softirqs last disabled at (3697567): [<ffff9f8c67360244>] __do_softirq+0x1c/0x28
---[ end trace 0000000000000000 ]---
Fixes: b58e12a ("drm/msm: Add _NO_SHARE flag")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665355/
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Aug 19, 2025
submit_unpin_objects() should come before we unlock the objects. This
fixes the splat:
WARNING: CPU: 2 PID: 2171 at drivers/gpu/drm/msm/msm_gem.h:395 msm_gem_unpin_locked+0x8c/0xd8 [msm]
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm qcom_pd_mapper cdc_mbim cdc_wdm cdc_ncm r8153_ecm cdc_ether usbnet sunrpc nls_ascii nls_cp437 vfat fat snd_soc_x1e80100 snd_soc_lpass_rx_macro snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_wsa_macro snd_soc_qcom_common soundwire_qcom snd_soc_lpass_macro_common snd_soc_hdmi_codec snd_soc_qcom_sdw ext4 snd_soc_core snd_compress soundwire_bus snd_pcm_dmaengine snd_seq mbcache jbd2 snd_seq_device snd_pcm pm8941_pwrkey snd_timer r8152 qcom_spmi_temp_alarm industrialio snd lenovo_yoga_slim7x ath12k mii arm_smccc_trng soundcore rng_core evdev loop panel_samsung_atna33xc20 msm ubwc_config drm_client_lib drm_gpuvm drm_exec gpu_sched drm_display_helper pmic_glink_altmode aux_hpd_bridge ucsi_glink qcom_battmgr phy_qcom_qmp_combo ps883x cec aux_bridge drm_dp_aux_bus i2c_hid_of aes_ce_blk drm_kms_helper aes_ce_cipher i2c_hid qcom_q6v5_pas
ghash_ce qcom_pil_info drm sha1_ce qcom_common phy_snps_eusb2 qcom_geni_serial qcom_q6v5 qcom_sysmon pinctrl_sm8550_lpass_lpi lpasscc_sc8280xp sbsa_gwdt mdt_loader gpio_keys pmic_glink i2c_dev efivarfs autofs4
CPU: 2 UID: 1000 PID: 2171 Comm: gnome-shell Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : msm_gem_unpin_locked+0x8c/0xd8 [msm]
lr : msm_gem_unpin_locked+0x88/0xd8 [msm]
sp : ffff80009c963820
x29: ffff80009c963820 x28: ffff80009c9639f8 x27: ffff00080552a830
x26: 0000000000000000 x25: ffff0009d5655800 x24: 0000000000000000
x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
x20: ffff000831db5480 x19: ffff000816e74400 x18: 0000000000000000
x17: 0000000000000000 x16: ffffc1396afdd720 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff0008c065bc00
x11: ffff0008c065c000 x10: 0000000000000000 x9 : ffffc13945b19074
x8 : 0000000000000000 x7 : 0000000000000209 x6 : 0000000000000002
x5 : 0000000000019d01 x4 : ffff0008ba8db080 x3 : 000000000004093f
x2 : ffff3ed5e727f000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
msm_gem_unpin_locked+0x8c/0xd8 [msm] (P)
msm_ioctl_gem_submit+0x32c/0x1760 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 2185036
hardirqs last enabled at (2185035): [<ffffc1396afeef9c>] _raw_spin_unlock_irqrestore+0x74/0x80
hardirqs last disabled at (2185036): [<ffffc1396afd8164>] el1_dbg+0x24/0x90
softirqs last enabled at (2184778): [<ffffc13969675e44>] fpsimd_restore_current_state+0x3c/0x328
softirqs last disabled at (2184776): [<ffffc13969675e14>] fpsimd_restore_current_state+0xc/0x328
---[ end trace 0000000000000000 ]---
Fixes: 111fdd2 ("drm/msm: drm_gpuvm conversion")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665357/
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 19, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 21, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Signed-off-by: Tony Ambardar <[email protected]>
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Aug 21, 2025
If we hit an error path in GEM obj creation before msm_gem_new_handle()
updates obj->resv to point to the gpuvm resv object, then obj->resv
still points to &obj->_resv. In this case we don't want to decrement
the refcount of the object being freed (since the refcnt is already
zero). This fixes the following splat:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 9 PID: 7013 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_da>
qcom_pil_info i2c_hid drm_kms_helper qcom_common qcom_q6v5 phy_snps_eusb2 qcom_geni_serial drm qcom_sysmon pinctrl_s>
CPU: 9 UID: 1000 PID: 7013 Comm: deqp-vk Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xf4/0x148
lr : refcount_warn_saturate+0xf4/0x148
sp : ffff8000a2073920
x29: ffff8000a2073920 x28: 0000000000000010 x27: 0000000000000010
x26: 0000000000000042 x25: ffff000810e09800 x24: 0000000000000010
x23: ffff8000a2073b94 x22: ffff000ddb22de00 x21: ffff000ddb22dc00
x20: ffff000ddb22ddf8 x19: ffff0008024934e0 x18: 000000000000000a
x17: 0000000000000000 x16: ffff9f8c67d77340 x15: 0000000000000000
x14: 00000000ffffffff x13: 2e656572662d7265 x12: 7466612d65737520
x11: 3b776f6c66726564 x10: 00000000ffff7fff x9 : ffff9f8c67506c70
x8 : ffff9f8c69fa26f0 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
x5 : ffff000f53e14548 x4 : ffff6082ea2b2000 x3 : ffff0008b86ab080
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008b86ab080
Call trace:
refcount_warn_saturate+0xf4/0x148 (P)
msm_gem_free_object+0x248/0x260 [msm]
drm_gem_object_free+0x24/0x40 [drm]
msm_gem_new+0x1c4/0x1e0 [msm]
msm_gem_new_handle+0x3c/0x1a0 [msm]
msm_ioctl_gem_new+0x38/0x70 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 3698694
hardirqs last enabled at (3698693): [<ffff9f8c675021dc>] __up_console_sem+0x74/0x90
hardirqs last disabled at (3698694): [<ffff9f8c68ce8164>] el1_dbg+0x24/0x90
softirqs last enabled at (3697578): [<ffff9f8c6744ec5c>] handle_softirqs+0x454/0x4b0
softirqs last disabled at (3697567): [<ffff9f8c67360244>] __do_softirq+0x1c/0x28
---[ end trace 0000000000000000 ]---
Fixes: b58e12a ("drm/msm: Add _NO_SHARE flag")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665355/
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Aug 21, 2025
submit_unpin_objects() should come before we unlock the objects. This
fixes the splat:
WARNING: CPU: 2 PID: 2171 at drivers/gpu/drm/msm/msm_gem.h:395 msm_gem_unpin_locked+0x8c/0xd8 [msm]
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm qcom_pd_mapper cdc_mbim cdc_wdm cdc_ncm r8153_ecm cdc_ether usbnet sunrpc nls_ascii nls_cp437 vfat fat snd_soc_x1e80100 snd_soc_lpass_rx_macro snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_wsa_macro snd_soc_qcom_common soundwire_qcom snd_soc_lpass_macro_common snd_soc_hdmi_codec snd_soc_qcom_sdw ext4 snd_soc_core snd_compress soundwire_bus snd_pcm_dmaengine snd_seq mbcache jbd2 snd_seq_device snd_pcm pm8941_pwrkey snd_timer r8152 qcom_spmi_temp_alarm industrialio snd lenovo_yoga_slim7x ath12k mii arm_smccc_trng soundcore rng_core evdev loop panel_samsung_atna33xc20 msm ubwc_config drm_client_lib drm_gpuvm drm_exec gpu_sched drm_display_helper pmic_glink_altmode aux_hpd_bridge ucsi_glink qcom_battmgr phy_qcom_qmp_combo ps883x cec aux_bridge drm_dp_aux_bus i2c_hid_of aes_ce_blk drm_kms_helper aes_ce_cipher i2c_hid qcom_q6v5_pas
ghash_ce qcom_pil_info drm sha1_ce qcom_common phy_snps_eusb2 qcom_geni_serial qcom_q6v5 qcom_sysmon pinctrl_sm8550_lpass_lpi lpasscc_sc8280xp sbsa_gwdt mdt_loader gpio_keys pmic_glink i2c_dev efivarfs autofs4
CPU: 2 UID: 1000 PID: 2171 Comm: gnome-shell Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : msm_gem_unpin_locked+0x8c/0xd8 [msm]
lr : msm_gem_unpin_locked+0x88/0xd8 [msm]
sp : ffff80009c963820
x29: ffff80009c963820 x28: ffff80009c9639f8 x27: ffff00080552a830
x26: 0000000000000000 x25: ffff0009d5655800 x24: 0000000000000000
x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
x20: ffff000831db5480 x19: ffff000816e74400 x18: 0000000000000000
x17: 0000000000000000 x16: ffffc1396afdd720 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff0008c065bc00
x11: ffff0008c065c000 x10: 0000000000000000 x9 : ffffc13945b19074
x8 : 0000000000000000 x7 : 0000000000000209 x6 : 0000000000000002
x5 : 0000000000019d01 x4 : ffff0008ba8db080 x3 : 000000000004093f
x2 : ffff3ed5e727f000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
msm_gem_unpin_locked+0x8c/0xd8 [msm] (P)
msm_ioctl_gem_submit+0x32c/0x1760 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 2185036
hardirqs last enabled at (2185035): [<ffffc1396afeef9c>] _raw_spin_unlock_irqrestore+0x74/0x80
hardirqs last disabled at (2185036): [<ffffc1396afd8164>] el1_dbg+0x24/0x90
softirqs last enabled at (2184778): [<ffffc13969675e44>] fpsimd_restore_current_state+0x3c/0x328
softirqs last disabled at (2184776): [<ffffc13969675e14>] fpsimd_restore_current_state+0xc/0x328
---[ end trace 0000000000000000 ]---
Fixes: 111fdd2 ("drm/msm: drm_gpuvm conversion")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665357/
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 28, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Aug 29, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 2, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 5, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 8, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 10, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Sep 10, 2025
If we hit an error path in GEM obj creation before msm_gem_new_handle()
updates obj->resv to point to the gpuvm resv object, then obj->resv
still points to &obj->_resv. In this case we don't want to decrement
the refcount of the object being freed (since the refcnt is already
zero). This fixes the following splat:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 9 PID: 7013 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_da>
qcom_pil_info i2c_hid drm_kms_helper qcom_common qcom_q6v5 phy_snps_eusb2 qcom_geni_serial drm qcom_sysmon pinctrl_s>
CPU: 9 UID: 1000 PID: 7013 Comm: deqp-vk Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xf4/0x148
lr : refcount_warn_saturate+0xf4/0x148
sp : ffff8000a2073920
x29: ffff8000a2073920 x28: 0000000000000010 x27: 0000000000000010
x26: 0000000000000042 x25: ffff000810e09800 x24: 0000000000000010
x23: ffff8000a2073b94 x22: ffff000ddb22de00 x21: ffff000ddb22dc00
x20: ffff000ddb22ddf8 x19: ffff0008024934e0 x18: 000000000000000a
x17: 0000000000000000 x16: ffff9f8c67d77340 x15: 0000000000000000
x14: 00000000ffffffff x13: 2e656572662d7265 x12: 7466612d65737520
x11: 3b776f6c66726564 x10: 00000000ffff7fff x9 : ffff9f8c67506c70
x8 : ffff9f8c69fa26f0 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
x5 : ffff000f53e14548 x4 : ffff6082ea2b2000 x3 : ffff0008b86ab080
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008b86ab080
Call trace:
refcount_warn_saturate+0xf4/0x148 (P)
msm_gem_free_object+0x248/0x260 [msm]
drm_gem_object_free+0x24/0x40 [drm]
msm_gem_new+0x1c4/0x1e0 [msm]
msm_gem_new_handle+0x3c/0x1a0 [msm]
msm_ioctl_gem_new+0x38/0x70 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 3698694
hardirqs last enabled at (3698693): [<ffff9f8c675021dc>] __up_console_sem+0x74/0x90
hardirqs last disabled at (3698694): [<ffff9f8c68ce8164>] el1_dbg+0x24/0x90
softirqs last enabled at (3697578): [<ffff9f8c6744ec5c>] handle_softirqs+0x454/0x4b0
softirqs last disabled at (3697567): [<ffff9f8c67360244>] __do_softirq+0x1c/0x28
---[ end trace 0000000000000000 ]---
Fixes: b58e12a ("drm/msm: Add _NO_SHARE flag")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665355/
MatthewCroughan
pushed a commit
to MatthewCroughan/linux
that referenced
this pull request
Sep 10, 2025
submit_unpin_objects() should come before we unlock the objects. This
fixes the splat:
WARNING: CPU: 2 PID: 2171 at drivers/gpu/drm/msm/msm_gem.h:395 msm_gem_unpin_locked+0x8c/0xd8 [msm]
Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm qcom_pd_mapper cdc_mbim cdc_wdm cdc_ncm r8153_ecm cdc_ether usbnet sunrpc nls_ascii nls_cp437 vfat fat snd_soc_x1e80100 snd_soc_lpass_rx_macro snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_wsa_macro snd_soc_qcom_common soundwire_qcom snd_soc_lpass_macro_common snd_soc_hdmi_codec snd_soc_qcom_sdw ext4 snd_soc_core snd_compress soundwire_bus snd_pcm_dmaengine snd_seq mbcache jbd2 snd_seq_device snd_pcm pm8941_pwrkey snd_timer r8152 qcom_spmi_temp_alarm industrialio snd lenovo_yoga_slim7x ath12k mii arm_smccc_trng soundcore rng_core evdev loop panel_samsung_atna33xc20 msm ubwc_config drm_client_lib drm_gpuvm drm_exec gpu_sched drm_display_helper pmic_glink_altmode aux_hpd_bridge ucsi_glink qcom_battmgr phy_qcom_qmp_combo ps883x cec aux_bridge drm_dp_aux_bus i2c_hid_of aes_ce_blk drm_kms_helper aes_ce_cipher i2c_hid qcom_q6v5_pas
ghash_ce qcom_pil_info drm sha1_ce qcom_common phy_snps_eusb2 qcom_geni_serial qcom_q6v5 qcom_sysmon pinctrl_sm8550_lpass_lpi lpasscc_sc8280xp sbsa_gwdt mdt_loader gpio_keys pmic_glink i2c_dev efivarfs autofs4
CPU: 2 UID: 1000 PID: 2171 Comm: gnome-shell Not tainted 6.16.0-rc4-debug+ torvalds#25 PREEMPT(voluntary)
Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
pstate: 6140000 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : msm_gem_unpin_locked+0x8c/0xd8 [msm]
lr : msm_gem_unpin_locked+0x88/0xd8 [msm]
sp : ffff80009c963820
x29: ffff80009c963820 x28: ffff80009c9639f8 x27: ffff00080552a830
x26: 0000000000000000 x25: ffff0009d5655800 x24: 0000000000000000
x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
x20: ffff000831db5480 x19: ffff000816e74400 x18: 0000000000000000
x17: 0000000000000000 x16: ffffc1396afdd720 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff0008c065bc00
x11: ffff0008c065c000 x10: 0000000000000000 x9 : ffffc13945b19074
x8 : 0000000000000000 x7 : 0000000000000209 x6 : 0000000000000002
x5 : 0000000000019d01 x4 : ffff0008ba8db080 x3 : 000000000004093f
x2 : ffff3ed5e727f000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
msm_gem_unpin_locked+0x8c/0xd8 [msm] (P)
msm_ioctl_gem_submit+0x32c/0x1760 [msm]
drm_ioctl_kernel+0xc8/0x138 [drm]
drm_ioctl+0x2c8/0x618 [drm]
__arm64_sys_ioctl+0xac/0x108
invoke_syscall.constprop.0+0x64/0xe8
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x54/0x1d8
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x19c/0x1a0
irq event stamp: 2185036
hardirqs last enabled at (2185035): [<ffffc1396afeef9c>] _raw_spin_unlock_irqrestore+0x74/0x80
hardirqs last disabled at (2185036): [<ffffc1396afd8164>] el1_dbg+0x24/0x90
softirqs last enabled at (2184778): [<ffffc13969675e44>] fpsimd_restore_current_state+0x3c/0x328
softirqs last disabled at (2184776): [<ffffc13969675e14>] fpsimd_restore_current_state+0xc/0x328
---[ end trace 0000000000000000 ]---
Fixes: 111fdd2 ("drm/msm: drm_gpuvm conversion")
Signed-off-by: Rob Clark <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/665357/
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 11, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 13, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 16, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 17, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 18, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 19, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 20, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 21, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
With test_progs compiled with ARM THUMB insns, trigger_func*() used for testing uprobes have odd (LSB set) entry points due to interworking. This fails alignment check first, then due to uprobe unsupported for THUMB in prepare_uprobe() -> arch_uprobe_analyze_insn() -> arm_probes_decode_insn(). First fix by setting trigger_func*() as ARM insns and rely on interworking enabled by default. Doesn't work on Debian bookworm target because insn #1 of funcs patched to 'UDF torvalds#25' which causes "Illegal instruction". Patched by dynamic loader? Kernel somehow? __attribute__((target("arm"))) Works to compile all test_progs with gcc -marm, or just attach_probe.c. Change Makefile to compile prog_tests/attach_probe.c with '-marm' to avoid using THUMB insns, with expected tests passing: torvalds#8/1 attach_probe/manual-default:OK torvalds#8/2 attach_probe/manual-legacy:OK torvalds#8/3 attach_probe/manual-perf:OK torvalds#8/4 attach_probe/manual-link:OK torvalds#8/5 attach_probe/auto:OK torvalds#8/6 attach_probe/kprobe-sleepable:OK torvalds#8/8 attach_probe/uprobe-sleepable:OK torvalds#8/9 attach_probe/uprobe-ref_ctr:OK torvalds#8/10 attach_probe/uprobe-long_name:OK torvalds#8/11 attach_probe/kprobe-long_name:OK torvalds#8 attach_probe:OK Note that attach_probe/uprobe-lib will still fail since it tries to attach a uprobe to the system libc.so, which is compiled for THUMB: test_attach_probe:PASS:skel_open 0 nsec test_attach_probe:PASS:skel_load 0 nsec test_attach_probe:PASS:check_bss 0 nsec test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf: prog 'handle_uprobe_byname2': failed to create uprobe '/lib/arm-linux-gnueabihf/libc.so.6:0x528e1' perf event: -EINVAL test_uprobe_lib:FAIL:attach_uprobe_byname2 unexpected error: -22 torvalds#8/7 attach_probe/uprobe-lib:FAIL torvalds#8 attach_probe:FAIL Also compile other source files and binary with same issue using "-marm": bpf_cookie.c fill_link_info.c task_pt_regs.test.c uprobe_autoattach.c (also tries libc.so attach) usdt.c uprobe_multi Signed-off-by: Tony Ambardar <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
added support for "foxconn hon/hai 0489:e027" bluetooth which is an Atheros 3011 chip