Doing some testing against a change; I ran two traces. Recording the trace before applying the patch as trace-b.dat and then calling the trace file after applying the patch as trace-a.dat. Then doing an ls trace*.dat I have:

trace-a.dat
trace-b.dat

And it looks like trace-a.dat should come before trace-b.dat. I’m so confused! 😛

Looks like a lot of people are still without power in Portland. Linus gets a surprise vacation during the merge window 🫤

I’m being “schooled” by Al Viro on how dcache, inodes, and files work internally.

This is a very interesting read that I recommend anyone that wants to understand VFS better should look at.

And don’t just stop at that email, the thread goes on. Very educational. Hopefully someone smarter than I can add this to the VFS documentation in the kernel 😉

Allow ring buffer to have bigger sub buffers

Hmm, that subject line may not have been appropriate. 🤔

@gregkh @vbabka @qyousef Well the problem is that it still requires manual effort to even include the clean up patch. The point I was making is that if a clean up patch causes a backport to fail, I still have to look at why instead of it just nicely being pulled in by the stable tag. The clean up in question, touched much more than the areas that failed, so it too may not backport properly.

@qyousef @vbabka Which, BTW is exactly what happened here! 😛

@qyousef @vbabka Exactly. If you do clean ups in the code that you are modifying then all is OK, because the modifications you are making will cause the backports to fail anyway, so the clean ups do not cause extra work. But if you just have random clean ups in code that hasn’t changed in years, if a bug in that code is found, then the backports are going to be a pain fixing all previous version before the “cleanup”.

@vbabka @qyousef I just wasted over an hour fixing patches that should have gone back automatically without my involvement. I don’t think 1/0 vs true/false is worth it. Note, I’m doing this on my own time, where I have other things I rather be doing.

@qyousef Although, I just hit another patch that did not backport properly because of that change 😛 This means I’m going to NACK all clean up changes from now on, citing that it breaks backports.

@qyousef false better than 0 is more for understanding that the value is a boolean an not to be taken as numeric. Sometimes that makes it easier to understand the logic. I’ve been trying to use boolean in those cases as well. This also is a requirement if you ever plan on using Rust 😉

I don’t mind clean up patches, but this is the reason a lot of Linux kernel maintainers frown on them.

https://lore.kernel.org/all/2023120938-unclamped-fleshy-688e@gregkh/

This failure is because of a clean up patch that converted everything to “bool” where it could be:

https://lore.kernel.org/all/20230305155532.5549-3-ubizjak@gmail.com/T/#u

If I had not accepted that clean up, this backport would have been pulled in automatically with no extra work from myself. But because I added that clean up, I now have to fix this for every stable release before that clean up 🙁

@vbabka But now I have to go look at what came about in 3.13 that got rid of the concept of a normal kernel.

@vbabka Heh, I didn’t mean normal as the kernel itself was normal. I meant normal as in the kernel that Fedora normally boots up by default.

Ha! ktest.pl already does this!

https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git/commit/?h=for-next&id=ac2466456eaa0ff9b8cf647c4c52832024bc929f

Thank you Masayoshi Mizuma! You only added this feature back in 2019 🤪

Except, it looks like it overwrote the default kernel, making my machine not able to boot the normal kernel. Had to play magic to get it back booting again.

Grub2 tries to make it so easy that it makes it suck for simply things.

@oleksandr I have several test boxes that have various boot loaders. This one I haven’t touched in a while, and is the first time I noticed it. It seems to be the default for Fedora (which I’m a Debian guy). I need to get it to work for ktest.pl anyway, as others may need it.

OK, finally fixed it with:

grubby --add-kernel=/boot/vmlinuz-test --initrd=/boot/initramfs-test.img --title 'Test Kernel'

But now I have to figure out how to have ktest read this shit and know which option to set grub-reboot to.

I really hate grub2. Now they hide the menu entries in a separate directory. This really makes it difficult when testing kernels and adding tweaks to the command line. It now doesn’t seem to find my test kernel and I have no idea how to make it do so. 😠

@ljs @lkundrak @ptesarik @vbabka Honestly, I didn’t notice until now.

@ptesarik @ljs @vbabka Noted. There’s a lot of bad annotations, and most of them I ignore because they are not obvious that they are indeed wrong. Things like “stats” use to be unlikely (before they were switched over to static_branch). Because they were runtime switches and the idea is “if you have it disabled, you likely want it to be faster”. So having it enabled would be 100% incorrect. But that was indeed the correct outcome.

Before sending any patch to fix or remove a likely/unlikely() I analyze it to understand the reason it is incorrect. I never blindly send a patch because the tool said so. I send it after I understand the situation. A lot of the fixes I have done were because the likely use to be correct, but a change occurred that made it incorrect. One example of this was a case that a condition was added before the unlikely annotation condition to always be true. The added condition exited the function in 90% of the cases that would have caused the unlikely condition to be unlikely. Now when that condition is hit, it was 90% likely.

Here’s an article I wrote while at VMware. Read it now before they take it down (VMware no longer exists!) I need to copy it too.