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
Tokamak has quit [Quit: Tokamak]
mraynal has quit [Read error: Connection reset by peer]
<arnd>
I don't think I've seen one of those before, usually there is a clear culprit when this happens
headless has quit [Quit: Konversation terminated!]
macromorgan has joined #armlinux
<ardb>
this is why we have IRQ stacks now
<rfs613>
for those using GPG to sign your git commits, and who do a lot of rebasing: do you notice the GPG overhead?
<broonie>
It's visible but not especially.
heat has joined #armlinux
<broonie>
More like you can see a slight stutter than it's actually slow.
<rfs613>
i've not measured yet, but seemed like an extra second per commit. When you have 100+ commits that adds up...
torez has joined #armlinux
<broonie>
It'll depend on how exactly you've got your key set up and so on.
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
<rfs613>
broonie: do you mean using ed25519 versus RSA, or something besides that?
<broonie>
Using a smartcard might impact performance as well.
<rfs613>
better or worse?
<broonie>
yes :P
<rfs613>
hrm...
<broonie>
I'd guess more likely slower.
heat_ has quit [Remote host closed the connection]
heat_ has joined #armlinux
<ukleinek>
having to type the passphrase for each signing process also slows things a bit :-)
<broonie>
Yeah, you need to use gpg-agent.
heat_ is now known as heat
frieder has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
<[florian]>
arnd: cool, thanks a lot, and sorry for being insistant. This patch means that kernel headers need to be re-generated so the sooner they land, the better, especially with 4.9 being sunset in a few months
<[florian]>
arnd: we have seen a number of self inflicted larger than 8KB stack, but in the most part with proper analysis they can be solved
<[florian]>
and as ardb says, there is now IRQ stacks, so not really a problem anymore
plappermaul has joined #armlinux
plappermaul has quit [Quit: Client closed]
plappermaul has joined #armlinux
apritzel__ has quit [Ping timeout: 248 seconds]
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #armlinux
amitk has quit [Ping timeout: 260 seconds]
headless has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
viorel_suman has quit [Quit: WeeChat 3.5]
<arnd>
ardb, [florian]: unfortunately the bug report was about stable-5.15.y, which lacks IRQ stacks and will be with us for a while longer. I don't think we can realistically backport that, and it seems to happen occasionally on the board. Not sure if it's always the same call chain, but I might go one step further and rebuild that kernel with -Wframe-larger-than=1 to see how much each function in that call chain actually consumes.
prabhakarlad has joined #armlinux
<[florian]>
arnd: this is a really extreme case though
<arnd>
agreed, it's just really annoying because this is the main platform for LKFT to test 32-bit arm
heat_ has joined #armlinux
heat has quit [Ping timeout: 252 seconds]
plappermaul has quit [Quit: Client closed]
heat_ has quit [Read error: Connection reset by peer]
heat has joined #armlinux
apritzel has joined #armlinux
heat_ has joined #armlinux
heat has quit [Ping timeout: 252 seconds]
torez has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
heat has joined #armlinux
prabhakarlad has joined #armlinux
heat_ has quit [Read error: Connection reset by peer]
<arnd>
For most functions, gcc -Wframe-larger-than=1 doesn't warn at all, which I think just means it allocates no local variables on the stack aside from setting up the frame for unwinding
<arnd>
and reworking print_constraints_debug is unlikely to make a real difference here\
<arnd>
ardb: one thing I noticed is that this kernel forces the use of UNWINDER_FRAME_POINTER because it enables FUNCTION_GRAPH_TRACER. That costs a few bytes for each of the 147 functions in the backtrace, right? I wonder if we could backport your 41918ec82eb6 ("ARM: ftrace: enable the graph tracer with the EABI unwinder") and have nkambo use the Arm unwinder instead
headless has quit [Quit: Konversation terminated!]
<[florian]>
arnd: I wish there was a tool that could somehow give you ahead of time the maximum stack depth possible, but it would be kind of hard to do with preemption
<arnd>
[florian]: I think joern wrote a tool for that some 15 years ago and found countless cases of unbound recursion. E.g. in nkambo's report most of the call chain is for the six-level deep nested DT device probing, but nothing in the kernel puts an upper bound on those
<[florian]>
arnd: yes I bet it did
<[florian]>
arnd: where is that tool?
<arnd>
I don't know if he ever published it, probably wouldn't work on modern kernels anyway