On a related note. I finally switched my .emacs file to use xref-find-definitions instead of the find-tags which has been obsolete since 2016!

I believe I win the Procastination Award for the time between sending a v2 after a v1 patch. I had a patch to fix make TAGS to not include structure members and posted it to the mailing list. I received reviews to make it better, but things came up and I never got around to sending a v2. I left the conversation in my INBOX and every time I saw it, I would say to myself “Oh, I’ll have to finish that later”. In the mean time I would just manually apply the patch via quilt push whenever I did a make TAGS. I finally got around to sending the v2. The v1 was sent out in 2013!!! It’s only been 13 years since I wrote v1 😛

@ljs @ptesarik That code also fixed doing a full stack trace dump of every task (sysrq-t) when an NMI discovered a lock up. Stack traces can fault, which would re-enable NMIs, and because every task's stack trace is being printed to the console in NMI context, another NMI would trigger, corrupting the stack of the first NMI and crash the system before all the stack traces could be printed. This was annoying when trying to debug hard lockups.

@ljs @ptesarik I missed the post and only saw the replies. Could you email me the original if you still have it. I'm curious to what you said. Don't worry, I won't hold it against you 😉

@ptesarik @ljs https://lwn.net/Articles/484932/

For those of you that submit content to Linux Plumbers, you will be able to buy tickets for the conference two weeks before it opens. And if your content gets you a free pass, yes, you will be refunded.

https://lpc.events/blog/current/index.php/2026/04/06/changes-to-registration-availability-for-2026/

Reminder. Linux Plumbers CFP is open for Refereed and Kernel Summit talks, as well as for BoFs and Microconference Tracks.

https://lpc.events/blog/current/index.php/2026/03/23/submission-time-for-linux-plumbers-2026/

I love how vibecoded commits are called vommits. It's so perfect.

I should also say that the code is much more complex than what it was back then.

@notbobbytables The reason for this option, is that ktest.pl can take a MIN_CONIFG option where you pass the minimal config options that allow your box to boot. This is useful, because you can take someone else’s config (that you may need to debug), use that to build, and ktest.pl will add your min conifg on top, to make sure your box will build.

Now you have a kernel that is as close to possible as the kernel of the person that sent you their config. This is extremely useful when you need to debug their environment.

@notbobbytables You should check out ktest.pl’s make_min_config option. If you have ktest.pl set up, this option will have ktest “bisect” a bunch of configs until it gives you minimal config that boots the board (and optionally runs a test). At the end of the test, if you disable any config, it will not boot.

@ljs I can’t wait to see you on “flying pig airlines!”

21 years ago today, I posted streamline_config.pl.

Which most of you now know it as make localmodconfig.

I thought this was the appropriate shirt to wear to my colonoscopy today.

trace-cmd 3.4 has been released!

What’s new? The biggest change is that if you record with function or function graph tracer and enable the func-args or funcgraph-args then trace-cmd will save the BTF file (/sys/kernel/btf/vmlinux) in the trace.dat and use it for trace-cmd report to show the functions:

 function:             mutex_unlock(lock=0xffffffff831dbbe0)
 function:             __mutex_unlock_slowpath(lock=0xffffffff831dbbe0, ip=0xffffffff814a7154)
 function:             __f_unlock_pos(f=0xffff8881538de000)
 function:             mutex_unlock(lock=0xffff8881538de090)
 function:             __mutex_unlock_slowpath(lock=0xffff8881538de090, ip=0xffffffff816e8ed1)
 function:             mem_cgroup_handle_over_high(gfp_mask=0xcc0)

Also, if you run trace-cmd extract on a persistent ring buffer, it will save the last_boot_info file (and /proc/modules) and use it to properly calculate the addresses of the functions from the previous boot to the addresses of the same functions of the current boot so that it can properly get their names from the saved kallsyms. This way you can even see all the functions that did the reboot!

boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:             native_machine_emergency_restart()
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                tboot_shutdown(shutdown_type=0x0)
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                machine_real_restart(type=0x0)
boot_mapped:            <...>-1     [000] d..1.  6869.910269: function:                   _raw_spin_lock(lock=0xffffffff95d03214)
boot_mapped:            <...>-1     [000] d..2.  6869.910269: function:                   rtc_cmos_write(val=0x0, addr=0x8f)
boot_mapped:            <...>-1     [000] d..2.  6869.910276: function:                   _raw_spin_unlock(lock=0xffffffff95d03214)
boot_mapped:            <...>-1     [000] d..1.  6869.910277: function:                   load_trampoline_pgtable()
boot_mapped:            <...>-1     [000] d..1.  6869.910277: function:                   __flush_tlb_all()
boot_mapped:            <...>-1     [000] d..1.  6869.910278: function:                      native_flush_tlb_global()

libtraceevent 1.9 has been released!

What’s new? Support for loading BTF and printing function arguments. Also, processing of the persistent ring buffer. It adds APIs to be able to map the function addresses from the previous boot to address of the current boot so that their names can be found from kallsyms.

@vbabka @DesnoyersMa I’ve sent Linus default y configs before. But I always mention “this keeps previous behavior”. What gets him pissed off is when you send a default y for a new feature. If it’s something that doesn’t change his config, he hasn’t complained to me about it before.

@DesnoyersMa The default needs to keep how it is today the same. For hiding, it would be default N.

@DesnoyersMa I would actually make it CONFIG_HIDE_TRACE_PRINTK to allow those that don't want it included to be able to have that option. As right now it's something people want that build their kernels.

I’m fighting to keep trace_printk.h in kernel.h. If you use trace_printk() for debugging, and do not want to have to add:

#include <linux/trace_printk.h>

to every file you you want to add a trace_printk() to, please make yourself heard and respond to this email thread.

Otherwise, trace_printk() will become a bit more tedious to use.

https://lore.kernel.org/all/20251229111748.3ba66311@gandalf.local.home/