might bug in file_system or bash #301
Open
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
might find
|
This is certainly not a bug, it's working as intended (POSIX.2-compliance). Read section Bash FAQ E10 and this. |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 9, 2018
The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 11, 2018
The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 18, 2018
The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Feb 28, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Feb 28, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
amery
referenced
this pull request
in linux-sunxi/linux-sunxi
Feb 28, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
dm0-
referenced
this pull request
in coreos/linux
Feb 28, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
dm0-
referenced
this pull request
in coreos/linux
Feb 28, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Mar 8, 2018
[ Upstream commit 01ea306 ] The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Jun 1, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Jun 17, 2018
commit 01ea306 upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by: Xin Long <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ torvalds#301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59a ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: [email protected] Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Ben Hutchings <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Sep 1, 2020
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
[ 21.083506] ------------[ cut here ]------------
[ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
lr: c0000000005eeeec: pte_update+0x11c/0x190
sp: c000000c6d1e7950
msr: 8000000002029033
current = 0xc000000c6d172c80
paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
pid = 1, comm = swapper/0
kernel BUG at arch/powerpc/mm/pgtable.c:304!
Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#301 SMP Tue Sep 1 02:28:29 CDT 2020
enter ? for help
[link register ] c0000000005eeeec pte_update+0x11c/0x190
[c000000c6d1e7950] 0000000000000001 (unreliable)
[c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
[c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
[c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
[c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
[c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
[c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
[c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
With DEBUG_VM disabled
[ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
[ 20.530183] Faulting instruction address: 0xc0000000000df330
cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
pc: c0000000000df330: memset+0x68/0x104
lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
sp: c000000c6d19f990
msr: 8000000002009033
dar: 0
current = 0xc000000c6d177480
paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
pid = 1, comm = swapper/0
Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#302 SMP Tue Sep 1 02:56:02 CDT 2020
enter ? for help
[link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
[c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
[c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
[c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
[c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
[c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
[c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
[c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
33:mon>
Signed-off-by: Aneesh Kumar K.V <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 1, 2020
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
[ 21.083506] ------------[ cut here ]------------
[ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
lr: c0000000005eeeec: pte_update+0x11c/0x190
sp: c000000c6d1e7950
msr: 8000000002029033
current = 0xc000000c6d172c80
paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
pid = 1, comm = swapper/0
kernel BUG at arch/powerpc/mm/pgtable.c:304!
Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#301 SMP Tue Sep 1 02:28:29 CDT 2020
enter ? for help
[link register ] c0000000005eeeec pte_update+0x11c/0x190
[c000000c6d1e7950] 0000000000000001 (unreliable)
[c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
[c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
[c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
[c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
[c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
[c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
[c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
With DEBUG_VM disabled
[ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
[ 20.530183] Faulting instruction address: 0xc0000000000df330
cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
pc: c0000000000df330: memset+0x68/0x104
lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
sp: c000000c6d19f990
msr: 8000000002009033
dar: 0
current = 0xc000000c6d177480
paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
pid = 1, comm = swapper/0
Linux version 5.9.0-rc2-34902-g4da73871507c (kvaneesh@ltczz75-lp2) (gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) torvalds#302 SMP Tue Sep 1 02:56:02 CDT 2020
enter ? for help
[link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
[c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
[c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
[c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
[c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
[c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
[c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
[c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
33:mon>
Signed-off-by: Aneesh Kumar K.V <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Dec 16, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 19, 2020
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
chleroy
added a commit
to chleroy/linux
that referenced
this pull request
Feb 12, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Mar 22, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]>
mpe
pushed a commit
to linuxppc/linux
that referenced
this pull request
Apr 3, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/fbc3e4fcc9c8f6131d6c705212530b2aa50149ee.1616430991.git.christophe.leroy@csgroup.eu
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Apr 8, 2021
At the time being, PPC32 has Classical BPF support. The test_bpf module exhibits some failure: test_bpf: torvalds#298 LD_IND byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#299 LD_IND halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#301 LD_IND halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: torvalds#303 LD_ABS byte frag jited:1 ret 202 != 66 FAIL (1 times) test_bpf: torvalds#304 LD_ABS halfword frag jited:1 ret 51958 != 17220 FAIL (1 times) test_bpf: torvalds#306 LD_ABS halfword mixed head/frag jited:1 ret 51958 != 1305 FAIL (1 times) test_bpf: Summary: 371 PASSED, 7 FAILED, [119/366 JIT'ed] Fixing this is not worth the effort. Instead, remove support for classical BPF and prepare for adding Extended BPF support instead. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/fbc3e4fcc9c8f6131d6c705212530b2aa50149ee.1616430991.git.christophe.leroy@csgroup.eu
TheSven73
pushed a commit
to TheSven73/linux
that referenced
this pull request
May 27, 2021
Simple Rust driver that touches real hardware: PR 3/6
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 24, 2023
A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
mpe
added a commit
to linuxppc/linux
that referenced
this pull request
Oct 22, 2023
A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Fixes: 6895dfc ("powerpc: copy_thread fill in interrupt frame marker and back chain") Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 15, 2023
[ Upstream commit d45c4b4 ] A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Fixes: 6895dfc ("powerpc: copy_thread fill in interrupt frame marker and back chain") Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 19, 2023
[ Upstream commit d45c4b4 ] A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Fixes: 6895dfc ("powerpc: copy_thread fill in interrupt frame marker and back chain") Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit d45c4b4 ] A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Fixes: 6895dfc ("powerpc: copy_thread fill in interrupt frame marker and back chain") Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
charwliu
pushed a commit
to charwliu/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit d45c4b4 ] A thread started via eg. user_mode_thread() runs in the kernel to begin with and then may later return to userspace. While it's running in the kernel it has a pt_regs at the base of its kernel stack, but that pt_regs is all zeroes. If the thread oopses in that state, it leads to an ugly stack trace with a big block of zero GPRs, as reported by Joel: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc7-00004-gf7757129e3de-dirty #3 Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 PowerNV Call Trace: [c0000000036afb00] [c0000000010dd058] dump_stack_lvl+0x6c/0x9c (unreliable) [c0000000036afb30] [c00000000013c524] panic+0x178/0x424 [c0000000036afbd0] [c000000002005100] mount_root_generic+0x250/0x324 [c0000000036afca0] [c0000000020057d0] prepare_namespace+0x2d4/0x344 [c0000000036afd20] [c0000000020049c0] kernel_init_freeable+0x358/0x3ac [c0000000036afdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c0000000036afe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 NIP: 0000000000000000 LR: 0000000000000000 CTR: 0000000000000000 REGS: c0000000036afe80 TRAP: 0000 Not tainted (6.5.0-rc7-00004-gf7757129e3de-dirty) MSR: 0000000000000000 <> CR: 00000000 XER: 00000000 CFAR: 0000000000000000 IRQMASK: 0 GPR00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [0000000000000000] 0x0 LR [0000000000000000] 0x0 --- interrupt: 0 The all-zero pt_regs looks ugly and conveys no useful information, other than its presence. So detect that case and just show the presence of the frame by printing the interrupt marker, eg: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00126-g18e9506562a0-dirty torvalds#301 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: [c000000003aabb00] [c000000001143db8] dump_stack_lvl+0x6c/0x9c (unreliable) [c000000003aabb30] [c00000000014c624] panic+0x178/0x424 [c000000003aabbd0] [c0000000020050fc] mount_root_generic+0x250/0x324 [c000000003aabca0] [c0000000020057cc] prepare_namespace+0x2d4/0x344 [c000000003aabd20] [c0000000020049bc] kernel_init_freeable+0x358/0x3ac [c000000003aabdf0] [c0000000000111b0] kernel_init+0x30/0x1a0 [c000000003aabe50] [c00000000000debc] ret_from_kernel_user_thread+0x14/0x1c --- interrupt: 0 at 0x0 To avoid ever suppressing a valid pt_regs make sure the pt_regs has a zero MSR and TRAP value, and is located at the very base of the stack. Fixes: 6895dfc ("powerpc: copy_thread fill in interrupt frame marker and back chain") Reported-by: Joel Stanley <[email protected]> Reported-by: Nicholas Piggin <[email protected]> Reviewed-by: Joel Stanley <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[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.
might a bug but this might can't be a bug