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.

cheers

the moods on facebook/linkedin/fediverse are quite different. everyone seems to be normal on facebook/linkedin, but on fediverse.... hmm :)

watching a tutorial on Oppenheimer before going to the cinema

Making a small progress on one of my TODOs: run automatic builds & tests using CI tools for MM development kernels

This is a jenkins configuration matrix specially targeting SLUB to cover various SLUB configurations. Only boot test is done atm.

There are many milestones on this project, which demands more time :P

TIL1 - There are three types of scheduling tick reduction mechanism (NO_HZ_FULL, NO_HZ_IDLE, HZ_PERIODIC).

NO_HZ_IDLE reduces scheduling ticks only when a CPU is idle (for energy efficiency). This is the default.

NO_HZ_FULL reduces scheduling ticks when there is only one runnable task per CPU. (used on HPC workloads or realtime applications)

HZ_PERIODIC never reduces scheduling ticks.

TIL2 - The mechnism of the Linux buddy allocator's PCP (per cpu pages) draining was recently changed from interprocessor interrupts, to workqueue, and then remote draining from the CPU that invokes draining. I knew that this exists - but took a closer look during this week's my local kernel study session.

The latest change is quite useful because it does not need to wait for other CPUs to drain their PCP locally, and nohz full CPUs does not need to stop what they were doing and drain their local PCPs.

TIL:
While modern programming languages are specified in context-free or context-sensitive grammars, regular languages are still used for tokenizing the source code because regular language is limited but powerful.

The lexical specification of a typical programming language is written in regular language.

The computational unit that understands regular languages are finite automata. To implement an automaton, a nondeterministic automata that processes a regular expression is created first, and then it is converted to deterministic finite automata for fast processing.

For quite some time now, I've had two concerns on my career:

The first one is to find a position that allows me to work on (public or internal) kernel stuff, and possibly contribute to the upstream kernel. This is important because I want to work on what I want to.

The other one is to find a position that allows me to observe functional/performance issues on production workloads, fix them and do performance engineering. This is important too because a huge gain on a workload that does not occur in the real world is useless.

I'm not sure if such positions are common and not even sure if they are compatible :/

Lessons learned today:

- Your theoretical expectation on something is very prone to error and do not believe it even when you are very sure. Prove it by data.

- Do not measure the outcome of multiple changes at once.

- Do not create an account with a very simple password on a publicly available computer, someone will log into it and eat your CPUs.

Me with my friends

When there are no free pages in free list of the requested order, buddy allocator splits a larger page into smaller ones, and allocates a one of the split pages.

TIL: The way buddy splits large pages (and allocating first or last part of a large page) during the expand() function significantly impacts the mergability of the scatter-gather list for IO. The likeliness that pages are allocated in PFN order is important for mergability. This is so subtle and I didn't realize this :(

Consider a scenario where there is only an order 2 block, and four order 0 requests are served. In the diagram above, they are allocated in PFN order, while in the other diagram, they are allocated in the reverse order.

https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=c75b81a5da09be94099cf7b46bdb32fedc8ce71a

And in the history this thing has introduced a regression because the order was not preserved (by mistake) when pages are allocated from PCP lists with __GFP_COLD ;)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4

DAMON user-space tool (damo) has released[1] its 100th version. A mail[2] for the news, release stats, and appreciation to the DAMON community has also posted. From the mail:

"Looking forward to 200th, and 1,000th release of damo :D We, the community,
will make it together."

[1] https://github.com/awslabs/damo/releases/tag/v1.9.3
[2] https://lore.kernel.org/damon/20230807202044.98700-1-sj@kernel.org/

#linux #kernel #damon #damo

something big is coming

damn it's too hot

Beef tartare

I've just built my first 2 socket server (36C/72T, DDR4 256GB ECC/REG RAM) for experimenting with NUMA.
It's an old xeon server (Broadwell), but enough to play with!

Sometimes my schedule goes out of control, and I find myself buried in the work I started. It can be overwhelming, and this is one of those moments.

However, there is some good news: it's likely that I will be participating in a field exercise program next semester at a startup that designs CXL devices.

It's a very nice opportunity, but at the same time, it's a pity that I'll be missing some classes!

How am I supposed to take it out