06:40 <tmlind> arnd: sounds like the am335x regression was a false positive on the vmap stack changes

06:41 <tmlind> i'll suggest bisecting with vmap stack always disabled

06:42 <arnd> tmlind: but vmap-stack was disabled before the patches he bisected to, so unless there was a mistake during bisection, the trigger is still in the same few patches

06:42 <tmlind> arnd: yeah so it seems, now vmap stack gets enabled by default

06:43 <tmlind> arnd: so the v6 and thread save local changes could be it, we had some of those recently, right?

06:45 <arnd> from the patches in the bisection, I would guess it's something in 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")

06:46 <tmlind> right

06:47 <arnd> this appears to enable THREAD_INFO_IN_TASK, IRQSTACKS and STACKPROTECTOR_PER_TASK, all of which would be disabled before this for the V6 SMP config

06:48 <tmlind> yeah i'll suggest testing before and after that commit

06:48 <arnd> I thought those failed to work because of another bug, so he couldn't bisect further

06:49 <arnd> but if the problem is still there without SMP and MULTI_v6, it's likely that the problem already existed before the patches but was hidden because CURRENT_POINTER_IN_TPIDRURO depends on !CPU_V6

06:50 <tmlind> yes could be

06:55 <tmlind> arnd: for the musb dma issues, seems that the driver data just needs to add void __iomem *buf to have it available for transferring the remaining bytes after dma :)

06:56 <tmlind> that should get rid of all the pre dma enagine crap

07:01 <ardb> maybe the IRQ stacks are the issue, although i'm not sure how

10:10 <ardb> arnd: tmlind, ok so it seems related to the SMP_ON_UP patching of the TPIDR register reads into loads of cpu_offset and/or __current

10:10 <ardb> (that would be my guess, anyway)

10:12 <tmlind> ardb: ok

10:13 <ardb> tmlind: this is a UP Cortex-A8, right?

10:25 <tmlind> ardb: yes am335x is up c-a8

11:26 <arnd> I suppose we really should have removed that support and made SMP depend on !CPU_V6 back then, but now we have to fix it

11:27 <arnd> or at least understand the exact problem before deciding it's too hard to fix ;-)

11:36 <arnd> ardb: I was just looking at use of tasklets in dmaengine for entirely different reasons, but there is always a chance that this is related: cppi41_dma_callback() runs from a tasklet in softirq context, and it gets into another network softirq through the can driver, which may then trigger running ksoftirqd

11:37 <arnd> most other drivers wouldn't run into that particular combination, at least not reproducibly

12:11 <arnd> I went through possible code paths involving softirq or the smp-patched TPIDR. So far I did not find what I was looking for, but maz might like to hear that handle_IPI() can now be removed

12:12 <arnd> marked as obsolete in 56afcd3dbd19 ("ARM: Allow IPIs to be handled as normal interrupts"), last caller removed in 08572cd41955 ("ARM: remove some dead code")

14:08 <arnd> krzk: I'm going through the patchwork contents at the moment to see what is missing that should still be part of rc1, and there are a ton of patches from you. I assume the three "dma-channels" cleanups are meant for 5.19, and the whitespace stuff is for 5.20?

14:14 <ukleinek> arnd: some days ago we discussed about KASAN_STACK. In the end I found it enabled with COMPILE_TEST on arm and I understood you were surprised by that too. Ist that right?

14:15 <arnd> ukleinek: correct. I don't know exactly what happened here, the best explanation I have is that there was a compile-time check in the past that turned KASAN_STACK into a nop on gcc

14:17 <arnd> maybe nathanchance's 19532869feb9 ("kasan: always respect CONFIG_KASAN_STACK") turned it off for clang but on for gcc?

14:17 <arnd> I have a number of patches on top of my randconfig build tree, and may have missed that

14:20 <ukleinek> 19532869feb9 looks innocent to me

14:26 <ukleinek> in v5.11 KASAN was disabled for allmodconfig ARCH=arm

14:26 <ukleinek> in v5.12 it was already on

14:28 <ukleinek> 02c587733c8161355a43e6e110c2e29bd0acff72 is the first bad commit

14:33 <ukleinek> ah, that however only changes CONFIG_KASAN_STACK=1 to CONFIG_KASAN_STACK=y, so my bisect script was wrong

14:34 <ukleinek> in v5.0 KASAN_STACK=1, too, with allmodconfig

15:25 <ukleinek> it seems KASAN is effectively on since 421015713b306e47af95d4d61cdfbd96d462e4cb, seems to be by design

16:38 <mwalle> arnd: thanks, btw that link somehow has a trailing quote: https://git.kernel.org/soc/soc/c/01ba87a4b792

16:39 <mwalle> arnd: dunno if that a problem of your tool or if you just have clumsy fingers

17:15 <ukleinek> arnd: I think KASAN was never disabled for ARCH=arm?!

17:17 <arnd> kasan itself was added for arm in 5.11, late 2020. I don't think the behavior is arm specific though, the extra stack usage happens on all architectures, and is more noticeable on 32-bit architectures because of the lower default warning limit

17:21 <ukleinek> so what is the action item? Look at each warning and fix?