Learning how to write a LAVA test definition, but the tricker thing is to decide which tests to run to verify a kernel works fine.

Candidates:
- LTP
- KUnit
- kselftests

btw it is funny that the entire LTP suite gets killed every time it runs oom testcases. and LTP takes quite long time for a lightweight testing.

hmm... maybe run only a smaller subset of them?

Today I learned:

CXL memory can be mapped as 'System RAM' or 'Soft Reserved' by platform firmware. Or it can be dynamically provisioned by (since v6.3) CXL region driver.

And 'Soft Reserved' or dynamically provisioned CXL RAM region can be used in two ways:

1. Applications mmap() to /dev/daxX.Y files, just like traditional persistent memory devices.
2. Kernel use it as System RAM via dax_kmem driver.

And a weird fact is that when dax_kmem onlines CXL (and other performance-differentiated like pmem) memory, to ZONE_NORMAL, not ZONE_MOVABLE.

Working on a series for 6.8 probably...
So far...
26 files changed, 39 insertions(+), 4375 deletions(-)

Booting the latest kernel is always fun ;)

I was hit by BUG_ON() because I enabled CONFIG_DEBUG_VIRTUAL=y.
It made my machine crash and I wrote and sent a quick hack to fix this.

https://lore.kernel.org/lkml/CAB=+i9QiJ=BXkQuCFJTh3dMXrkKQvVA2EM51Mj6SsDMimWQ71g@mail.gmail.com

Today I learned:

- Better to use proper tags for regzbot next time I report something, don't make @kernellogger do that instead of me.

- __init and __exit are compiler attributes that makes functions to be in specific ELF sections (.init.text and .exit.text), to drop portions of unused kernel code.

- When a kernel feature is built into kernel rather than built as a module, functions marked __init are dropped after initialization and functions marked __exit are dropped and never used. because you can't unload a built-in kernel feature ;)

- Some architectures drop .exit.text section at link time, but some drop at runtime. this is due to complexity of link-time reference counting between functions (? which I have no idea yet)

- On architectures that drop it at runtime, functions marked __exit are dropped in free_initmem() because .exit.text section is between __init_begin and __init_end.

- I need an automatic bisection system to save time in the future.

One piece of information I'm missing here is why it did not crash before the commit :(

"[…] Instead of accepting my [#LinuxKernel] patch or guiding me towards a better solution, he went ahead and implemented his own fix, giving me credit only for reporting the issue […]

My first contribution to the [#Linux] #kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work. […]"

https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/

1/ Side note: I sometimes wonder if…

My android phone kills the chrome app very often. It is painful that I can't see system logs. I suspect it was the OOM killer that kills it.

Raspberry Pi 5 announced - still tiny, much more powerful https://www.gamingonlinux.com/2023/09/raspberry-pi-5-announced-still-tiny-much-more-powerful/

#RaspberryPi5 #RPi

nice 6 days break for Chuseok! (korean thanksgiving day)
@sj 즐거운 추석 되세요 :)

Welcome to the cycle of generative AI making search worse.

Quora uses ChatGPT which hallucinates an answer to a nonsense question.

Google Search picks up this nonsense answer from Quora which has high page rank and treats it as an instant answer.

"Subscribing" to mailing lists via sourcing a pop3 mailbox from lore.kernel.org now works. Should be of particular interest to gmail users.

I'll document after some more initial testing.

small progress on the kernel testing side project: I did setup LAVA instance in addition to Jenkins and made it publicly available.

it took few weeks due to issues with hardware :(

this is home server so can't provide excellent stability and uptime but here it is:

https://lava.kerneltesting.org
https://jenkins.kerneltesting.org

my jenkins VM was mysteriously shut down continuously without any log. I spent some time figuring out why, but it was the host's OOM killer that killed it. chrome tabs that I forgot to close was eating up 100% of the memory. fun ;)

but 32gib for a browser was too much? was it memory leak?

@ljs @vbabka You are very important person :)

I'm really excited about making Use-After-Free exploits much harder in the #Linux #kernel.

CONFIG_RANDOM_KMALLOC_CACHES has landed:
https://git.kernel.org/linus/3c6152940584

CONFIG_SLAB_VIRTUAL is coming:
https://lore.kernel.org/lkml/20230915105933.495735-15-matteorizzo@google.com/

writing code that will not be used at all is utterly frustrating and akin to creating garbage.

Buried in the work... feeling like being a piece of shit. Oh, I should visit this:

https://hypebeast.com/2023/9/joan-cornella-vip-solo-exhibition-allrightsreserved-meet-project-em-gallery-seoul

It has happened at last: after many iterations, that x86 shadow-stack patch series has been accepted into the mainline for 6.6:

https://lwn.net/ml/linux-kernel/CAHk-=wipDVFEfSJxbnUSDqENs5i8RzSsgJOFdb69pH=b7BOFiQ@mail.gmail.com/

For those who haven't been following this saga, see https://lwn.net/Articles/926649/

Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:

- The kernel security team does not have any "early notice"
announcement list for security fixes for anyone, as that would only
make things more insecure for everyone.

- The kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

- You HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random
patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system,
and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss
it with them as to how they achieve this result as this is what you
are paying for. If you aren't paying for it, just use Debian, they
know what they are doing and track the stable kernels and have a
larger installed base than any other Linux distro. For embedded,
use Yocto, they track the stable releases, or keep your own
buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before
putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about
1.5mil lines of code, embedded runs about 3.5mil lines of code, your
mileage will vary). If you can't test releases before moving them
into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a
future problem as future problems, when found, will be fixed then.

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...

As mentioned[1] to Lorenzo Stoakes, I'd like to buy a glass of beer to people who gave the first hundred stars to damo[2]. If you are in the first hundred group and find me from any offline venue, please let me know you're one of the group so that I can buy you a glass of beer :) I will attend the Open Source Summit Europe[3] and hopefully Linux Plumbers[4] for the rest of this year :)

[1] https://shorturl.at/szZ45
[2] https://github.com/awslabs/damo
[3] https://events.linuxfoundation.org/open-source-summit-europe/
[4] https://lpc.events/event/17/

#linux #kernel #damon #damo

On the radar: GCC security policy

I want to try a little experiment here. As I spend my day screwing around on the net, I come across a lot of conversations that may or may not eventually make good LWN articles. I'll toss one of those out here occasionally and see if people find it useful. Appearance here does not mean that I will (or will not) write something about it later, only that it has caught my attention.

The first topic is a few weeks old but still possibly interesting: the GCC folks are working to hammer out a security policy, which comes down to laying out what does — or does not — constitute a GCC security bug:

https://lwn.net/ml/gcc-patches/CAGWvny=z1yotE-6geJL1j80qSeZU67h-ZENPowM=BSNm0nHOVA@mail.gmail.com/

Strangely enough, it turns out that if you feed untrusted source to the compiler and the result bites you, they don't think it's a compiler bug.