@lkundrak lol how they are even tested

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

@jbowen what kind of positions have you applied for?
good luck anyway!

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/

@cwayne @vbabka maybe the flu or just powerful cold?

Hope everyone get well soon anyway!

@ljs @vbabka @lkundrak
too bad that I m not unkind enough to be tagged

@mntmn cool laptop XD
but be careful when it rains

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.

@ljs @cwayne the country most likely to have a war with is North Korea, which primarily has Korean food. too bad.

@cwayne adorable! how old is she?

So I measured one change (the SLUB numa locality change) at a time and the data seems to be nice I think? (at least on my old Broadwell machine with 2 sockets)

The "Neither a win nor a loss" situation was because one change was a win and the other change was a loss.

But it's still synthetic hackbench and I wonder how it would perform on network benchmarks - but not sure if I could benchmark this enough on local env cuz I only have 2.5Gbps lan cards.

@cwayne @ljs I've only ever tried Korean food or dishes from other cultures cooked in the Korean style :(

you're right :) I just wanted to note that we're close. I'm not into overthinking the whole 'best friends' thing.

@ljs but why nobody brought cuisine to british food?

@ljs what about british foods

@cwayne Haha, it's not me; he's my best friend who lives downstairs. I will introduce him to you if you want! :D

cheers