Thread (15 messages) read the whole thread 15 messages, 4 authors, 2021-03-17

Re: [syzbot] kernel panic: corrupted stack end in openat

From: Arnd Bergmann <arnd@arndb.de>
Date: 2021-03-16 16:29:35
Also in: linux-mm, lkml

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/ (local)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help