A ftrace selftest just failed due to the differences between bash and dash on how they interpret backslashes (\
).
Bash will evaluate it once, where as dash will evaluate it every time.
i=123
TEST="\\$i"
echo "$TEST"
Bash will show: \123
where as dash will echo out the escape sequence of “123”.
A kprobe event self test needed to test the max number of arguments, where each argument held a backslash followed by a number. It created it with the loop:
TEST_STRING=$1
# Acceptable
for i in `seq 1 $MAX_ARGS`; do
TEST_STRING="$TEST_STRING \\$i"
done
echo "$TEST_STRING" >> dynamic_events
Which worked fine when /bin/sh
was bash, but when /bin/sh
was dash, it failed!
And checkbashisms did NOT catch it!
Just added tab completion for trace-cmd sqlhist
for making synthetic events with the sql interface so much easier!
I’ve been wanting to add to trace-cmd start
a way to make it start quicker. It’s currently slow because it resets most of tracefs before starting, and that can take seconds.
I forgot I already have this feature! trace-cmd set
acts just like start, but it does not do the reset before starting. It’s very quick!
Note, it also does not re-enable tracing if it’s disabled. So you may want to run trace-cmd restart
right after that, if that’s the case.
-Werror
is great, until you need to debug an older kernel 😛
I think this is the first time I ever used the quadratic equation for a real purpose since college! 🤔
https://lore.kernel.org/lkml/20250204172045.3a5d8d01@gandalf.local.home/
Not every day you can say you were complemented by Linus Torvalds saying you had an “interesting idea”. Always look for those silver linings!
Fixing up a messed up Debian upgrade where I needed to reinstall, I had to hit “Select this only if you know what you are doing”. I don’t know what I’m doing, but I had to hit it to do what I needed to get done 😛
THIS IS IT!!!
The last hurdle for PREEMPT_RT being merged into mainline has just removed by this pull request. Leaving the door open for PREEMPT_RT to be added to 6.12!
With my new persistent memory mapped ring buffer, were I can retrieve the tracing buffer from the previous boot that crashed, I was able to debug a recent issue. To do this, I added code to allow trace_printk()
to be directed to the persistent ring buffer, along with enabling the printk console trace event (writes all printk()s to the tracing ring buffer), I was able to get the perfect idea of what was happening that lead up to the crash!
https://lore.kernel.org/lkml/20240823013902.135036960@goodmis.org/
A tribute to Daniel Bristot de Oliveira from Linux Plumbers. https://lpc.events/blog/current/index.php/2024/07/06/in-memory-of-daniel-bristot-de-oliveira/
Daniel Bristot de Oliveira passed away on Monday, June 24th at the age of 37. Another sad loss for the Linux kernel developer community, Daniel will be sorely missed.
In memory of Daniel: https://t.co/kQCQyTCo1a