ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
mraynal has quit [Remote host closed the connection]
saulosilva has joined #armlinux
mraynal has joined #armlinux
heat_ has quit [Ping timeout: 272 seconds]
apritzel has quit [Ping timeout: 248 seconds]
saulosilva has quit [Quit: Client closed]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #armlinux
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 244 seconds]
rvalue- is now known as rvalue
apritzel has joined #armlinux
monstr has joined #armlinux
apritzel has quit [Ping timeout: 244 seconds]
<linusw__>
ardb: had some fun with it, using some prints I see we actually end up on the overflow stack a bit on Vexpress QEMU
apritzel has joined #armlinux
<ardb>
linusw__: that should only happen when the stack overflows though
<ardb>
except perhaps on initial boot with the init stack
<linusw__>
ardb: so the overflow stack is only in use for CONFIG_VMAP_STACK and we need to check current SP (not regs-> sp) in that case. I think I got it. Also fixed my code.
<linusw__>
ardb: it's on initial boot I see it :D
<ardb>
fair enough
<linusw__>
hm a bit after boot as well. Maybe the stack is small?
<ardb>
i guess PID 1 may keep using the initial stack afterwards?
<linusw__>
hm yeah
<linusw__>
on debian that is like ... all of systemd
<linusw__>
so it will overflow in no time
cbeznea has joined #armlinux
<linusw__>
Even if I set up THREAD_SIZE_ORDER to something really big like 4, I still get sp < high_memory a lot when processing IRQs so I wonder what's going on here...
<linusw__>
It's less but still there.
<linusw__>
Normally SP is something like f0eaff20 in the VMALLOC area ~f0000000
<linusw__>
then off and on it is something like 80f0fe78, 80f0ff18 below high_memory
<linusw__>
(that is still in kernel memory as Vexpress uses 2G/2G split)
<linusw__>
I guess that is the static overflow stack so fair enough it is detected indeed but quite frequently used.
headless has joined #armlinux
headless has quit [Quit: Konversation terminated!]
tambarus has joined #armlinux
sszy has joined #armlinux
<ardb>
linusw__: that is not the overflow stack
<ardb>
it that gets used, you will notice by the big splat
<ardb>
does it coincide with the init_stack symbol?
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
<tambarus>
jon #pixel6-kernel-dev
heat_ has joined #armlinux
biju has joined #armlinux
tambarus has quit [Quit: Lost terminal]
apritzel has quit [Ping timeout: 244 seconds]
<linusw__>
ardb: not quite, init_stack is at 0x80f00000-0x80f01fff
<linusw__>
ardb: oh no you're right it's the init_stack, was looking at my other compile
<ardb>
so PID 1 always runs from the init stack in the linear map
<linusw__>
this one indeed is claiming 80f01e78, 80f01f18 etc
<linusw__>
ardb: right
<ardb>
it therefore doesn't use the IRQ stack but it doesn't use a VMAP'ed stack to begin with
<linusw__>
yeah the code works like such that it keeps using init_stack for IRQs that happen when we are executing PID 1 I believ
<linusw__>
since it assumes sp < high_memory == overflow stack is in use
<linusw__>
not the end of the world but I guess I should fix it?
<ardb>
well
<ardb>
depends on whether running from the init stack is a problem to begin with
<ardb>
this could also be fixed by moving PID1 to a VMAP'
<ardb>
ed stack
<linusw__>
more a problem of me knowing what is happening :D
<ardb>
i'd be inclined to fix that, rather than special case the IRQ stack logic
Perflosopher05 has joined #armlinux
Perflosopher0 has quit [Ping timeout: 252 seconds]
Perflosopher05 is now known as Perflosopher0
apritzel_ has joined #armlinux
<linusw__>
ardb: I *could* add code to actually check if sp is in __this_cpu(overflow_stack_ptr) .. + OVERFLOW_STACK_SIZE
<linusw__>
but I guess the current method is like that because it is fast?
<linusw__>
but hm yeah obviously it's better if PID 1 could migrate to a VMAPed stack, it's way safer.
<linusw__>
I added a if ((sp > (u8 *)init_stack) && (sp < (u8 *)(init_stack + sizeof(init_stack)))) to my C rewrite and now it is running PID 1 on its IRQ stack
<linusw__>
Its a bit special case but it works.
sudeepholla_ has quit [Ping timeout: 244 seconds]
<ardb>
how is that better?
<ardb>
the current behavior is never been a problem, and is not wrong per se
nsaenz_ has joined #armlinux
nsaenz has quit [Ping timeout: 248 seconds]
nsaenz_ has quit [Ping timeout: 260 seconds]
bencoh has quit [Ping timeout: 252 seconds]
bencoh has joined #armlinux
nsaenz has joined #armlinux
luispm has quit [Ping timeout: 244 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
heat_ has quit [Ping timeout: 248 seconds]
Peng_Fan has quit [Quit: Connection closed for inactivity]
hanetzer has quit [Ping timeout: 252 seconds]
iivanov_ has joined #armlinux
hanetzer has joined #armlinux
luispm has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
bencoh has quit [Ping timeout: 260 seconds]
bencoh has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<linusw__>
It moves PID 1 to a VMAP:ed stack? That is better.
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
<mrutland>
Just a correction: PID 1 *does* get a VMAP'd stack; the init_task is PID 0 and becomes the idle task for CPU 0.
<mrutland>
See rest_init(), where it forks off PID 1 with "user_mode_thread(kernel_init, NULL, CLONE_FS)", and then later becomes the idle thread via "cpu_startup_entry(CPUHP_ONLINE)"
nsaenz has quit [Remote host closed the connection]
<mrutland>
Can't you use the arm64 logic for this, i.e. go to the IRQ stack if not on the thread stack?
<mrutland>
then that'd have fewer assumptions about memory layout, and would work fine regardless of whether vmap'd stacks are in use generally
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<mrutland>
i.e. if (on_thread_stack()) { call_on_irq_stack(handle_arm_irq, regs); } else { handle_arm_irq(regs); }
<mrutland>
AFAICT on_thread_stack() should be cheaper than on_irq_stack()
clegoffic has quit [Read error: Connection reset by peer]
monstr has quit [Remote host closed the connection]
biju has quit [Ping timeout: 264 seconds]
biju has joined #armlinux
saulosilva has quit [Quit: Client closed]
siak has joined #armlinux
heat_ has joined #armlinux
<ardb>
mrutland: thanks for clearing that up
<ardb>
if it's ok for PID 0 to be the only task that retains a stack in the linear map, then we could do as you suggest in the C code
alpernebbi has quit [Ping timeout: 265 seconds]
<ardb>
the issue here is that linusw__ attempted to infer the intent of the asm
<ardb>
which deliberately does as little as possible, as it is asm
<ardb>
so moving this to C code seems like an appropriate occasion to fix it up
saulosilva has joined #armlinux
<mrutland>
I agree; FWIW, I think it's OK for now for the init_task to not use a VMAP'd stack (e.g. it doesn't on arm64, atm)
<mrutland>
It'd be *nice* to use a VMAP'd stack there, but it's going to require more invasive work, either to set that up before start_kernel() or to transition over at some funciton call boundary
saulosilva has quit [Quit: Client closed]
heat_ has quit [Remote host closed the connection]
heat has joined #armlinux
saulosilva has joined #armlinux
alpernebbi has joined #armlinux
siak has quit [Remote host closed the connection]
siak has joined #armlinux
System_Error has quit [Remote host closed the connection]
bjdooks has quit [Read error: Connection reset by peer]
jeeeun8 has joined #armlinux
bjdooks has joined #armlinux
luispm has quit [Quit: Leaving]
prabhakalad has quit [Ping timeout: 248 seconds]
apritzel_ has quit [Ping timeout: 246 seconds]
heat has quit [Ping timeout: 248 seconds]
heat has joined #armlinux
saulosilva has quit [Quit: Client closed]
<linusw__>
mrutland, ardb: indeed it must be PID 0
<linusw__>
mrutland: I actually implemented on_irq_stack() for ARM because we didn't have it already. And that does it's job.
biju has quit [Quit: Konversation terminated!]
<linusw__>
the problem here is that we're rewriting the also code that *switches to* the irq stack, and that needs to know not only if we were on the irq stack already, but also if we are candidate for switching to the irq stack
<linusw__>
and that was done with if sp < high_memory so we switch if sp is below vmalloc
<mrutland>
I understand that doesn't work
<linusw__>
but that means we would also switch the overflow stack which is also < high_memory and we don't wanna do that
<mrutland>
on_thread_stack() already exists on arm, look in rch/arm/include/asm/stacktrace.h"
<mrutland>
note that checking on_thread_stack() avoids transitioning to the IRQ stack from *another* stack, e.g. if you went task -> IRQ -> overflow -> IRQ
<linusw__>
ah so I use that ... I get it, so the overflow stack is (!on_irq_stack() && !on_thread_stack())
<linusw__>
sweet
<linusw__>
I'll try this
<mrutland>
No, the check is just as above: if (on_thread_stack()) { call_on_irq_stack(handle_arm_irq, regs); } else { handle_arm_irq(regs); }
<mrutland>
If you're on the thread stack, the IRQ stack is not in use
<linusw__>
ah right of course
<linusw__>
I'll try that.
<linusw__>
thansk!
<linusw__>
thanks!
<linusw__>
the else clause covers the overflow stack too, excellent
<rfs613>
linusw__: just FYI, over the holidays I booted 6.12 on armv4 using netwinder_defconfig
nsaenz has quit [Remote host closed the connection]
apritzel has joined #armlinux
heat has quit [Remote host closed the connection]
heat has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #armlinux
<linusw__>
rfs613: I boot it regularly too :D I have an automated build script and TFTP-boot so it's an easy regressiontest. My harddisk gets corrupted all the time though so I just boot from initramfs.
<rfs613>
linusw__: cool, didn't know anybody was still testing it. There's a 4MB limit on TFTP which is a bit of a headache.
<linusw__>
rfs613: I test most major reworks so you can actually use CLANG to compile a kernel for it, and enable CFI on it. It works, isn't even slow.
<linusw__>
Not that I know if security mitigations for Footbridge is a big need, it's more "if it works on the NetWinder it works on anything".
<rfs613>
hehe
<rfs613>
my last attempt was with a 4.19 kernel, so... 5 years or more at least... it was nice (and quite surprising) to see it boot 6.12 on my first try.
<rfs613>
i also discovered that I no longer have any PS/2 keyboard left ;-)
headless has quit [Quit: Konversation terminated!]
cbeznea has quit [Ping timeout: 244 seconds]
<linusw__>
mrutland, ardb: on_thread_stack() works like a charm, of course.
<linusw__>
thanks guys!
* linusw__
wonder if there are obvious solutions to the other hundreds of lines of code in generic entry...
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 246 seconds]
saulosilva has joined #armlinux
System_Error has quit [Remote host closed the connection]