Update abdac.c #143
Closed
Update abdac.c #143
+12
−14
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
dasty
pushed a commit
to dasty/linux
that referenced
this pull request
Nov 30, 2014
commit 021de3d upstream. After writting a test to try to trigger the bug that caused the ring buffer iterator to become corrupted, I hit another bug: WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238() Modules linked in: ipt_MASQUERADE sunrpc [...] CPU: 1 PID: 5281 Comm: grep Tainted: G W 3.16.0-rc3-test+ torvalds#143 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000 ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010 ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003 Call Trace: [<ffffffff81503fb0>] ? dump_stack+0x4a/0x75 [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c14df>] ? ring_buffer_iter_peek+0x2d/0x5c [<ffffffff810c6f73>] ? tracing_iter_reset+0x6e/0x96 [<ffffffff810c74a3>] ? s_start+0xd7/0x17b [<ffffffff8112b13e>] ? kmem_cache_alloc_trace+0xda/0xea [<ffffffff8114cf94>] ? seq_read+0x148/0x361 [<ffffffff81132d98>] ? vfs_read+0x93/0xf1 [<ffffffff81132f1b>] ? SyS_read+0x60/0x8e [<ffffffff8150bf9f>] ? tracesys+0xdd/0xe2 Debugging this bug, which triggers when the rb_iter_peek() loops too many times (more than 2 times), I discovered there's a case that can cause that function to legitimately loop 3 times! rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek() only deals with the reader page (it's for consuming reads). The rb_iter_peek() is for traversing the buffer without consuming it, and as such, it can loop for one more reason. That is, if we hit the end of the reader page or any page, it will go to the next page and try again. That is, we have this: 1. iter->head > iter->head_page->page->commit (rb_inc_iter() which moves the iter to the next page) try again 2. event = rb_iter_head_event() event->type_len == RINGBUF_TYPE_TIME_EXTEND rb_advance_iter() try again 3. read the event. But we never get to 3, because the count is greater than 2 and we cause the WARNING and return NULL. Up the counter to 3. Fixes: 69d1b83 "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Nov 30, 2014
Fix the checkpatch complaint regarding unnecessary line continuation. WARNING: Avoid unnecessary line continuations torvalds#143: FILE: ad7606_core.c:143: Signed-off-by: Sören Brinkmann <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
dormando
pushed a commit
to fastly/linux
that referenced
this pull request
Dec 17, 2014
commit 021de3d upstream. After writting a test to try to trigger the bug that caused the ring buffer iterator to become corrupted, I hit another bug: WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238() Modules linked in: ipt_MASQUERADE sunrpc [...] CPU: 1 PID: 5281 Comm: grep Tainted: G W 3.16.0-rc3-test+ torvalds#143 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000 ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010 ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003 Call Trace: [<ffffffff81503fb0>] ? dump_stack+0x4a/0x75 [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c14df>] ? ring_buffer_iter_peek+0x2d/0x5c [<ffffffff810c6f73>] ? tracing_iter_reset+0x6e/0x96 [<ffffffff810c74a3>] ? s_start+0xd7/0x17b [<ffffffff8112b13e>] ? kmem_cache_alloc_trace+0xda/0xea [<ffffffff8114cf94>] ? seq_read+0x148/0x361 [<ffffffff81132d98>] ? vfs_read+0x93/0xf1 [<ffffffff81132f1b>] ? SyS_read+0x60/0x8e [<ffffffff8150bf9f>] ? tracesys+0xdd/0xe2 Debugging this bug, which triggers when the rb_iter_peek() loops too many times (more than 2 times), I discovered there's a case that can cause that function to legitimately loop 3 times! rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek() only deals with the reader page (it's for consuming reads). The rb_iter_peek() is for traversing the buffer without consuming it, and as such, it can loop for one more reason. That is, if we hit the end of the reader page or any page, it will go to the next page and try again. That is, we have this: 1. iter->head > iter->head_page->page->commit (rb_inc_iter() which moves the iter to the next page) try again 2. event = rb_iter_head_event() event->type_len == RINGBUF_TYPE_TIME_EXTEND rb_advance_iter() try again 3. read the event. But we never get to 3, because the count is greater than 2 and we cause the WARNING and return NULL. Up the counter to 3. Fixes: 69d1b83 "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
Linus doesn't accept pull requests from GitHub. Consult https://github.com/torvalds/linux/blob/master/Documentation/HOWTO instead. |
tylerwhall
pushed a commit
to tylerwhall/linux
that referenced
this pull request
Mar 25, 2015
commit 021de3d upstream. After writting a test to try to trigger the bug that caused the ring buffer iterator to become corrupted, I hit another bug: WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238() Modules linked in: ipt_MASQUERADE sunrpc [...] CPU: 1 PID: 5281 Comm: grep Tainted: G W 3.16.0-rc3-test+ torvalds#143 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000 ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010 ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003 Call Trace: [<ffffffff81503fb0>] ? dump_stack+0x4a/0x75 [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c14df>] ? ring_buffer_iter_peek+0x2d/0x5c [<ffffffff810c6f73>] ? tracing_iter_reset+0x6e/0x96 [<ffffffff810c74a3>] ? s_start+0xd7/0x17b [<ffffffff8112b13e>] ? kmem_cache_alloc_trace+0xda/0xea [<ffffffff8114cf94>] ? seq_read+0x148/0x361 [<ffffffff81132d98>] ? vfs_read+0x93/0xf1 [<ffffffff81132f1b>] ? SyS_read+0x60/0x8e [<ffffffff8150bf9f>] ? tracesys+0xdd/0xe2 Debugging this bug, which triggers when the rb_iter_peek() loops too many times (more than 2 times), I discovered there's a case that can cause that function to legitimately loop 3 times! rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek() only deals with the reader page (it's for consuming reads). The rb_iter_peek() is for traversing the buffer without consuming it, and as such, it can loop for one more reason. That is, if we hit the end of the reader page or any page, it will go to the next page and try again. That is, we have this: 1. iter->head > iter->head_page->page->commit (rb_inc_iter() which moves the iter to the next page) try again 2. event = rb_iter_head_event() event->type_len == RINGBUF_TYPE_TIME_EXTEND rb_advance_iter() try again 3. read the event. But we never get to 3, because the count is greater than 2 and we cause the WARNING and return NULL. Up the counter to 3. Fixes: 69d1b83 "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
rzr
pushed a commit
to rzr/linux
that referenced
this pull request
Jul 26, 2015
commit 021de3d upstream. After writting a test to try to trigger the bug that caused the ring buffer iterator to become corrupted, I hit another bug: WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238() Modules linked in: ipt_MASQUERADE sunrpc [...] CPU: 1 PID: 5281 Comm: grep Tainted: G W 3.16.0-rc3-test+ torvalds#143 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000 ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010 ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003 Call Trace: [<ffffffff81503fb0>] ? dump_stack+0x4a/0x75 [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c138d>] ? rb_iter_peek+0x113/0x238 [<ffffffff810c14df>] ? ring_buffer_iter_peek+0x2d/0x5c [<ffffffff810c6f73>] ? tracing_iter_reset+0x6e/0x96 [<ffffffff810c74a3>] ? s_start+0xd7/0x17b [<ffffffff8112b13e>] ? kmem_cache_alloc_trace+0xda/0xea [<ffffffff8114cf94>] ? seq_read+0x148/0x361 [<ffffffff81132d98>] ? vfs_read+0x93/0xf1 [<ffffffff81132f1b>] ? SyS_read+0x60/0x8e [<ffffffff8150bf9f>] ? tracesys+0xdd/0xe2 Debugging this bug, which triggers when the rb_iter_peek() loops too many times (more than 2 times), I discovered there's a case that can cause that function to legitimately loop 3 times! rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek() only deals with the reader page (it's for consuming reads). The rb_iter_peek() is for traversing the buffer without consuming it, and as such, it can loop for one more reason. That is, if we hit the end of the reader page or any page, it will go to the next page and try again. That is, we have this: 1. iter->head > iter->head_page->page->commit (rb_inc_iter() which moves the iter to the next page) try again 2. event = rb_iter_head_event() event->type_len == RINGBUF_TYPE_TIME_EXTEND rb_advance_iter() try again 3. read the event. But we never get to 3, because the count is greater than 2 and we cause the WARNING and return NULL. Up the counter to 3. Fixes: 69d1b83 "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt <[email protected]> [bwh: Backported to 3.2: drop inapplicable spelling correction] Signed-off-by: Ben Hutchings <[email protected]>
xin3liang
pushed a commit
to xin3liang/linux
that referenced
this pull request
Nov 16, 2015
drivers: input: powerkey HISI use capability interface
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 24, 2016
Minchan Kim reported setting the following warning on a 32-bit system although it can affect 64-bit systems. WARNING: CPU: 4 PID: 1322 at mm/memcontrol.c:998 mem_cgroup_update_lru_size+0x103/0x110 mem_cgroup_update_lru_size(f44b4000, 1, -7): zid 1 lru_size 1 but empty Modules linked in: CPU: 4 PID: 1322 Comm: cp Not tainted 4.7.0-rc4-mm1+ torvalds#143 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000086 00000086 c2bc5a10 db3e4a97 c2bc5a54 db9d4025 c2bc5a40 db07b82a db9d0594 c2bc5a70 0000052a db9d4025 000003e6 db208463 000003e6 00000001 f44b4000 00000001 c2bc5a5c db07b88b 00000009 00000000 c2bc5a54 db9d0594 Call Trace: [<db3e4a97>] dump_stack+0x76/0xaf [<db07b82a>] __warn+0xea/0x110 [<db208463>] ? mem_cgroup_update_lru_size+0x103/0x110 [<db07b88b>] warn_slowpath_fmt+0x3b/0x40 [<db208463>] mem_cgroup_update_lru_size+0x103/0x110 [<db1b52a2>] isolate_lru_pages.isra.61+0x2e2/0x360 [<db1b6ffc>] shrink_active_list+0xac/0x2a0 [<db3f136e>] ? __delay+0xe/0x10 [<db1b772c>] shrink_node_memcg+0x53c/0x7a0 [<db1b7a3b>] shrink_node+0xab/0x2a0 [<db1b7cf6>] do_try_to_free_pages+0xc6/0x390 [<db1b8205>] try_to_free_pages+0x245/0x590 LRU list contents and counts are updated separately. Counts are updated before pages are added to the LRU and updated after pages are removed. The warning above is from a check in mem_cgroup_update_lru_size that ensures that list sizes of zero are empty. The problem is that node-lru needs to account for highmem pages if CONFIG_HIGHMEM is set. One impact of the implementation is that the sizes are updated in multiple passes when pages from multiple zones were isolated. This happens whether HIGHMEM is set or not. When multiple zones are isolated, it's possible for a debugging check in memcg to be tripped. This patch forces all the zone counts to be updated before the memcg function is called. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Tested-by: Minchan Kim <[email protected]> Reported-by: Minchan Kim <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 27, 2016
Minchan Kim reported setting the following warning on a 32-bit system although it can affect 64-bit systems. WARNING: CPU: 4 PID: 1322 at mm/memcontrol.c:998 mem_cgroup_update_lru_size+0x103/0x110 mem_cgroup_update_lru_size(f44b4000, 1, -7): zid 1 lru_size 1 but empty Modules linked in: CPU: 4 PID: 1322 Comm: cp Not tainted 4.7.0-rc4-mm1+ torvalds#143 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000086 00000086 c2bc5a10 db3e4a97 c2bc5a54 db9d4025 c2bc5a40 db07b82a db9d0594 c2bc5a70 0000052a db9d4025 000003e6 db208463 000003e6 00000001 f44b4000 00000001 c2bc5a5c db07b88b 00000009 00000000 c2bc5a54 db9d0594 Call Trace: [<db3e4a97>] dump_stack+0x76/0xaf [<db07b82a>] __warn+0xea/0x110 [<db208463>] ? mem_cgroup_update_lru_size+0x103/0x110 [<db07b88b>] warn_slowpath_fmt+0x3b/0x40 [<db208463>] mem_cgroup_update_lru_size+0x103/0x110 [<db1b52a2>] isolate_lru_pages.isra.61+0x2e2/0x360 [<db1b6ffc>] shrink_active_list+0xac/0x2a0 [<db3f136e>] ? __delay+0xe/0x10 [<db1b772c>] shrink_node_memcg+0x53c/0x7a0 [<db1b7a3b>] shrink_node+0xab/0x2a0 [<db1b7cf6>] do_try_to_free_pages+0xc6/0x390 [<db1b8205>] try_to_free_pages+0x245/0x590 LRU list contents and counts are updated separately. Counts are updated before pages are added to the LRU and updated after pages are removed. The warning above is from a check in mem_cgroup_update_lru_size that ensures that list sizes of zero are empty. The problem is that node-lru needs to account for highmem pages if CONFIG_HIGHMEM is set. One impact of the implementation is that the sizes are updated in multiple passes when pages from multiple zones were isolated. This happens whether HIGHMEM is set or not. When multiple zones are isolated, it's possible for a debugging check in memcg to be tripped. This patch forces all the zone counts to be updated before the memcg function is called. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Tested-by: Minchan Kim <[email protected]> Reported-by: Minchan Kim <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 27, 2016
Minchan Kim reported setting the following warning on a 32-bit system although it can affect 64-bit systems. WARNING: CPU: 4 PID: 1322 at mm/memcontrol.c:998 mem_cgroup_update_lru_size+0x103/0x110 mem_cgroup_update_lru_size(f44b4000, 1, -7): zid 1 lru_size 1 but empty Modules linked in: CPU: 4 PID: 1322 Comm: cp Not tainted 4.7.0-rc4-mm1+ torvalds#143 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000086 00000086 c2bc5a10 db3e4a97 c2bc5a54 db9d4025 c2bc5a40 db07b82a db9d0594 c2bc5a70 0000052a db9d4025 000003e6 db208463 000003e6 00000001 f44b4000 00000001 c2bc5a5c db07b88b 00000009 00000000 c2bc5a54 db9d0594 Call Trace: [<db3e4a97>] dump_stack+0x76/0xaf [<db07b82a>] __warn+0xea/0x110 [<db208463>] ? mem_cgroup_update_lru_size+0x103/0x110 [<db07b88b>] warn_slowpath_fmt+0x3b/0x40 [<db208463>] mem_cgroup_update_lru_size+0x103/0x110 [<db1b52a2>] isolate_lru_pages.isra.61+0x2e2/0x360 [<db1b6ffc>] shrink_active_list+0xac/0x2a0 [<db3f136e>] ? __delay+0xe/0x10 [<db1b772c>] shrink_node_memcg+0x53c/0x7a0 [<db1b7a3b>] shrink_node+0xab/0x2a0 [<db1b7cf6>] do_try_to_free_pages+0xc6/0x390 [<db1b8205>] try_to_free_pages+0x245/0x590 LRU list contents and counts are updated separately. Counts are updated before pages are added to the LRU and updated after pages are removed. The warning above is from a check in mem_cgroup_update_lru_size that ensures that list sizes of zero are empty. The problem is that node-lru needs to account for highmem pages if CONFIG_HIGHMEM is set. One impact of the implementation is that the sizes are updated in multiple passes when pages from multiple zones were isolated. This happens whether HIGHMEM is set or not. When multiple zones are isolated, it's possible for a debugging check in memcg to be tripped. This patch forces all the zone counts to be updated before the memcg function is called. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Tested-by: Minchan Kim <[email protected]> Reported-by: Minchan Kim <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 29, 2016
Minchan Kim reported setting the following warning on a 32-bit system although it can affect 64-bit systems. WARNING: CPU: 4 PID: 1322 at mm/memcontrol.c:998 mem_cgroup_update_lru_size+0x103/0x110 mem_cgroup_update_lru_size(f44b4000, 1, -7): zid 1 lru_size 1 but empty Modules linked in: CPU: 4 PID: 1322 Comm: cp Not tainted 4.7.0-rc4-mm1+ torvalds#143 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000086 00000086 c2bc5a10 db3e4a97 c2bc5a54 db9d4025 c2bc5a40 db07b82a db9d0594 c2bc5a70 0000052a db9d4025 000003e6 db208463 000003e6 00000001 f44b4000 00000001 c2bc5a5c db07b88b 00000009 00000000 c2bc5a54 db9d0594 Call Trace: [<db3e4a97>] dump_stack+0x76/0xaf [<db07b82a>] __warn+0xea/0x110 [<db208463>] ? mem_cgroup_update_lru_size+0x103/0x110 [<db07b88b>] warn_slowpath_fmt+0x3b/0x40 [<db208463>] mem_cgroup_update_lru_size+0x103/0x110 [<db1b52a2>] isolate_lru_pages.isra.61+0x2e2/0x360 [<db1b6ffc>] shrink_active_list+0xac/0x2a0 [<db3f136e>] ? __delay+0xe/0x10 [<db1b772c>] shrink_node_memcg+0x53c/0x7a0 [<db1b7a3b>] shrink_node+0xab/0x2a0 [<db1b7cf6>] do_try_to_free_pages+0xc6/0x390 [<db1b8205>] try_to_free_pages+0x245/0x590 LRU list contents and counts are updated separately. Counts are updated before pages are added to the LRU and updated after pages are removed. The warning above is from a check in mem_cgroup_update_lru_size that ensures that list sizes of zero are empty. The problem is that node-lru needs to account for highmem pages if CONFIG_HIGHMEM is set. One impact of the implementation is that the sizes are updated in multiple passes when pages from multiple zones were isolated. This happens whether HIGHMEM is set or not. When multiple zones are isolated, it's possible for a debugging check in memcg to be tripped. This patch forces all the zone counts to be updated before the memcg function is called. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Tested-by: Minchan Kim <[email protected]> Reported-by: Minchan Kim <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 29, 2016
Minchan Kim reported setting the following warning on a 32-bit system although it can affect 64-bit systems. WARNING: CPU: 4 PID: 1322 at mm/memcontrol.c:998 mem_cgroup_update_lru_size+0x103/0x110 mem_cgroup_update_lru_size(f44b4000, 1, -7): zid 1 lru_size 1 but empty Modules linked in: CPU: 4 PID: 1322 Comm: cp Not tainted 4.7.0-rc4-mm1+ torvalds#143 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000086 00000086 c2bc5a10 db3e4a97 c2bc5a54 db9d4025 c2bc5a40 db07b82a db9d0594 c2bc5a70 0000052a db9d4025 000003e6 db208463 000003e6 00000001 f44b4000 00000001 c2bc5a5c db07b88b 00000009 00000000 c2bc5a54 db9d0594 Call Trace: [<db3e4a97>] dump_stack+0x76/0xaf [<db07b82a>] __warn+0xea/0x110 [<db208463>] ? mem_cgroup_update_lru_size+0x103/0x110 [<db07b88b>] warn_slowpath_fmt+0x3b/0x40 [<db208463>] mem_cgroup_update_lru_size+0x103/0x110 [<db1b52a2>] isolate_lru_pages.isra.61+0x2e2/0x360 [<db1b6ffc>] shrink_active_list+0xac/0x2a0 [<db3f136e>] ? __delay+0xe/0x10 [<db1b772c>] shrink_node_memcg+0x53c/0x7a0 [<db1b7a3b>] shrink_node+0xab/0x2a0 [<db1b7cf6>] do_try_to_free_pages+0xc6/0x390 [<db1b8205>] try_to_free_pages+0x245/0x590 LRU list contents and counts are updated separately. Counts are updated before pages are added to the LRU and updated after pages are removed. The warning above is from a check in mem_cgroup_update_lru_size that ensures that list sizes of zero are empty. The problem is that node-lru needs to account for highmem pages if CONFIG_HIGHMEM is set. One impact of the implementation is that the sizes are updated in multiple passes when pages from multiple zones were isolated. This happens whether HIGHMEM is set or not. When multiple zones are isolated, it's possible for a debugging check in memcg to be tripped. This patch forces all the zone counts to be updated before the memcg function is called. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Tested-by: Minchan Kim <[email protected]> Reported-by: Minchan Kim <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Aug 26, 2016
…-fixes WARNING: line over 80 characters torvalds#111: FILE: arch/powerpc/kernel/elf_util_64.c:141: + pr_err("Symbol '%s' in common section.\n", name); WARNING: else is not generally useful after a break or return torvalds#121: FILE: arch/powerpc/kernel/elf_util_64.c:151: + return -ENOEXEC; + } else { WARNING: line over 80 characters torvalds#143: FILE: arch/powerpc/kernel/elf_util_64.c:174: + *(uint32_t *)location = value - (uint32_t)(uint64_t)location; WARNING: line over 80 characters torvalds#172: FILE: arch/powerpc/kernel/elf_util_64.c:249: + pr_err("%s: REL14 %li out of range!\n", obj_name, total: 0 errors, 4 warnings, 196 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/powerpc-adapt-elf64_apply_relocate_add-for-kexec_file_load.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Thiago Jung Bauermann <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
koct9i
pushed a commit
to koct9i/linux
that referenced
this pull request
Aug 27, 2016
…-fixes WARNING: line over 80 characters torvalds#111: FILE: arch/powerpc/kernel/elf_util_64.c:141: + pr_err("Symbol '%s' in common section.\n", name); WARNING: else is not generally useful after a break or return torvalds#121: FILE: arch/powerpc/kernel/elf_util_64.c:151: + return -ENOEXEC; + } else { WARNING: line over 80 characters torvalds#143: FILE: arch/powerpc/kernel/elf_util_64.c:174: + *(uint32_t *)location = value - (uint32_t)(uint64_t)location; WARNING: line over 80 characters torvalds#172: FILE: arch/powerpc/kernel/elf_util_64.c:249: + pr_err("%s: REL14 %li out of range!\n", obj_name, total: 0 errors, 4 warnings, 196 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/powerpc-adapt-elf64_apply_relocate_add-for-kexec_file_load.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Thiago Jung Bauermann <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 20, 2016
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 26, 2016
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 4, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 4, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
norov
pushed a commit
to norov/linux
that referenced
this pull request
Jan 6, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
norov
pushed a commit
to norov/linux
that referenced
this pull request
Jan 9, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 11, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 12, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 16, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 17, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Jan 19, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 23, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 23, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 25, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 25, 2017
…the-idr-checkpatch-fixes
WARNING: braces {} are not necessary for single statement blocks
torvalds#143: FILE: tools/testing/radix-tree/idr-test.c:88:
+ for (i = 0; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 0, 0, GFP_KERNEL) == i);
+ }
WARNING: braces {} are not necessary for single statement blocks
torvalds#167: FILE: tools/testing/radix-tree/idr-test.c:112:
+ for (i = 1; i < 10; i++) {
+ assert(idr_alloc(&idr, NULL, 1, 0, GFP_KERNEL) == i);
+ }
total: 0 errors, 2 warnings, 159 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
./patches/reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 20, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 21, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 24, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 25, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 1, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 10, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 11, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 15, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 20, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 28, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 30, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 3, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 7, 2025
This test currently fails on armhf: verify_success:PASS:skel 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:kfunc_call_test4 0 nsec verify_success:FAIL:retval unexpected retval: actual 4294966063 != expected -1234 torvalds#143/11 kfunc_call/kfunc_call_test4:FAIL The problem can be traced to using 'long' as a 64-bit type in bpf_testmod function bpf_kfunc_call_test4(), to force 64-bit signed arithmetic, which breaks down on 32-bit systems. Fix by explicitly using 's64' rather than long. 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
3 participants
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.
Some mini changes of int to void.