+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
There's no way to know for sure because there's no indication of the
stack pointer in this, so we don't know how much space remains.
Therefore we don't know whether this is something in the dumped
path, or an interrupt causing it.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
There's no way to know for sure because there's no indication of the
stack pointer in this, so we don't know how much space remains.
Therefore we don't know whether this is something in the dumped
path, or an interrupt causing it.
Agree, to know for sure we would need support for VMAP_STACK.
But do we really need to know it? If it's an interrupt on top, it does
not make any difference?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
Nice find. I see there was already a second report, so it seems to be
reproducible as well.
If you are able to trigger this reliably, you could try printing the frame
pointer while unwinding to see what is actually going on:
@@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where,
unsigned long from,
unsigned long end = frame + 4 + sizeof(struct pt_regs);
#ifdef CONFIG_KALLSYMS
- printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
- loglvl, where, (void *)where, from, (void *)from);
+ printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n",
+ loglvl, where, (void *)where, from, (void *)from, frame);
#else
printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
loglvl, where, from);
If that doesn't help, I could have a look at the binary to see which
functions in the call chain take a lot of stack space, if any.
Which exact compiler version do you use for building these
kernels? I can try doing a build with the same commit and config.
This one function is one that I have seen before when looking at build
warnings with KASAN:
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
Nice find. I see there was already a second report, so it seems to be
reproducible as well.
If you are able to trigger this reliably, you could try printing the frame
pointer while unwinding to see what is actually going on:
@@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where,
unsigned long from,
unsigned long end = frame + 4 + sizeof(struct pt_regs);
#ifdef CONFIG_KALLSYMS
- printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
- loglvl, where, (void *)where, from, (void *)from);
+ printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n",
+ loglvl, where, (void *)where, from, (void *)from, frame);
#else
printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
loglvl, where, from);
If that doesn't help, I could have a look at the binary to see which
functions in the call chain take a lot of stack space, if any.
Which exact compiler version do you use for building these
kernels? I can try doing a build with the same commit and config.
This one function is one that I have seen before when looking at build
warnings with KASAN:
quoted
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
It's available in gcr.io/syzkaller/syzbot container.
(syzbot should have been provided the compiler version, something
broke, I've filed https://github.com/google/syzkaller/issues/2498 for
this)
Yes, KASAN is not enabled on arm32 for now.
Re printing FP, syzbot does not use custom patches:
http://bit.do/syzbot#no-custom-patches
But this does not seem to be syzbot-specific. It seems that any arm32
stack overflow report will be unactionable, so I think it would be
useful to include this into the mainline kernel to make overflow
reports useful for everybody (and for syzbot as a side effect).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
On Tue, Mar 16, 2021 at 8:18 AM syzbot
quoted
quoted
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
[<818033d8>] (panic)
52 [<8181f5b8>] (__schedule)
0 [<81820430>] (preempt_schedule_common)
0 [<818204dc>] (preempt_schedule)
0 [<8048c7c0>] (kernel_init_free_pages)
148 [<804916ac>] (get_page_from_freelist
212 [<80493264>] (__alloc_pages_nodemask)
44 [<8042f034>] (page_cache_ra_unbounded)
36 [<8042f2c8>] (do_page_cache_ra)
28 [<8042f418>] (ondemand_readahead)
0 [<8042f894>] (page_cache_async_ra)
68 [<80420ac8>] (filemap_get_pages)
120 [<80421110>] (filemap_read)
36 [<804215f0>] (generic_file_read_iter)
8 [<805ff430>] (ext4_file_read_iter)
96 [<804da3cc>] (__kernel_read)
8 [<8073772c>] (integrity_kernel_read)
412 [<8073a78c>] (ima_calc_file_hash_tfm)
164 [<8073ad08>] (ima_calc_file_hash)
106 [<8073bf84>] (ima_collect_measurement)
332 [<80738fec>] (process_measurement)
24 [<8073979c>] (ima_file_check)
172 [<804ec66c>] (path_openat)
152 [<804ef670>] (do_filp_open)
40 [<804d79c4>] (do_sys_openat2)
Re printing FP, syzbot does not use custom patches:
http://bit.do/syzbot#no-custom-patches
But this does not seem to be syzbot-specific. It seems that any arm32
stack overflow report will be unactionable, so I think it would be
useful to include this into the mainline kernel to make overflow
reports useful for everybody (and for syzbot as a side effect).
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-03-16 15:52:18
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
On Tue, Mar 16, 2021 at 8:18 AM syzbot
quoted
quoted
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 11:02 AM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
On Tue, Mar 16, 2021 at 8:18 AM syzbot
quoted
quoted
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
I see ima_calc_field_array_hash_tfm() shows up as one of the larger
stack users, but not alarmingly high:
../security/integrity/ima/ima_crypto.c: In function
‘ima_calc_field_array_hash_tfm’:
../security/integrity/ima/ima_crypto.c:624:1: warning: the frame size
of 664 bytes is larger than 600 bytes [-Wframe-larger-than=]
none of the other functions from the call chain have more than 600 bytes
in this combination of config/compiler/sourcetree.
In combination, I don't get to more than ~2300 bytes:
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's just a stock Debian-provided gcc. Which I would assume also just
a plain gcc.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann [off-list ref] wrote:
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov [off-list ref] wrote:
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann [off-list ref] wrote:
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
quoted
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
On Wed, Mar 17, 2021 at 8:52 AM Dmitry Vyukov [off-list ref] wrote:
On Tue, Mar 16, 2021 at 5:28 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 5:13 PM Dmitry Vyukov [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 5:03 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 4:51 PM Russell King - ARM Linux admin
[off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
quoted
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
Right, unfortunately I don't see a smoking gun there either, unless you are
also using NFS or devicemapper.
Implementing VMAP_STACK as you suggested earlier is probably the
best way to figure out if there is an actual overrun of the stack.
Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
also help find out if we ever get close to the limit. This is probably
less work, but it might not actually help in this case.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Mar 17, 2021 at 9:32 AM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
quoted
quoted
[off-list ref] wrote:
quoted
On Tue, Mar 16, 2021 at 04:44:45PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Mar 16, 2021 at 11:17 AM Dmitry Vyukov [off-list ref] wrote:
quoted
The compiler is gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Ok, building with Ubuntu 10.2.1-1ubuntu1 20201207 locally, that's
the closest I have installed, and I think the Debian and Ubuntu versions
are generally quite close in case of gcc since they are maintained by
the same packagers.
... which shouldn't be a problem - that's just over 1/4 of the stack
space. Could it be the syzbot's gcc is doing something weird and
inflating the stack frames?
It's possible, I think that's really unlikely given that it's just Debian's
gcc, which is as close to mainline as the version I was using.
Uwe's DEBUG_STACKOVERFLOW patch from a while ago might
help if this was the problem though:
https://lore.kernel.org/linux-arm-kernel/20200108082913.29710-1-u.kleine-koenig@pengutronix.de/
My best guess is something going wrong in the interrupt
that triggered the preempt_schedule() which ended up calling
task_stack_end_corrupted() in schedule_debug(), as you suggested
earlier.
FWIW I see slightly larger frames with the config:
073ab64 <ima_calc_field_array_hash_tfm>:
8073ab64: e1a0c00d mov ip, sp
8073ab68: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl,
fp, ip, lr, pc}
8073ab6c: e24cb004 sub fp, ip, #4
8073ab70: e24ddfa7 sub sp, sp, #668 ; 0x29c
Yes, this is the one that the compiler complained about when warning
for stack over 600 bytes. It's not called in this call chain though.
quoted
page_alloc can also do reclaim, I had the impression that reclaim can
be quite heavy-weight in all respects.
Yes, that is another possibility. What writable file systems or swap
do you normally have mounted that it could be writing to, and on
what storage device?
Right, unfortunately I don't see a smoking gun there either, unless you are
also using NFS or devicemapper.
Implementing VMAP_STACK as you suggested earlier is probably the
best way to figure out if there is an actual overrun of the stack.
Alternatively, adding support for GCC_PLUGIN_STACKLEAK might
also help find out if we ever get close to the limit. This is probably
less work, but it might not actually help in this case.
VMAP_STACK is quite intrusive as far as I understand. For KASAN I
considered a simpler option: have a debug config that allocates an
extra page after the stack and mprotect's it. It wastes a physical
page per task (fine for a debug config), but I would assume should be
radically simpler to implement. In the end somebody implemented proper
VMAP_STACK support for KASAN, but I still think it may be a reasonable
compromise between time investment and value.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+arm32 maintainer
I think this is a real stack overflow on arm32, the stack is indeed deep.
Nice find. I see there was already a second report, so it seems to be
reproducible as well.
If you are able to trigger this reliably, you could try printing the frame
pointer while unwinding to see what is actually going on:
@@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where,
unsigned long from,
unsigned long end = frame + 4 + sizeof(struct pt_regs);
#ifdef CONFIG_KALLSYMS
- printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
- loglvl, where, (void *)where, from, (void *)from);
+ printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n",
+ loglvl, where, (void *)where, from, (void *)from, frame);
#else
printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
loglvl, where, from);
If that doesn't help, I could have a look at the binary to see which
functions in the call chain take a lot of stack space, if any.
Which exact compiler version do you use for building these
kernels? I can try doing a build with the same commit and config.
This one function is one that I have seen before when looking at build
warnings with KASAN:
quoted
quoted
[<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484)
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline])
[<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572)
ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can
use up 512 bytes, but KASAN sometimes triples this number. However, I see
you do not actually have KASAN enabled, so there is probably more to it.