Grateful swags that I got from #osseu

#ossummit #ossummit_eu #osseu #spain #bilboa

@corbet @sjvn Send the emails my way, no one seems to ever actually want to talk to _me_ about these support dates for some odd reason...

So OSS Europe was an interesting experience, this year, in a way.

I did my usual talk, and started with the usual section on kernel releases. When talking about stable updates I tossed in a quick mention that six-year support from the stable team was being phased out — something I understood to be generally known for about the last year. Way at the end of the talk, as my last topic, I discussed at some length the stresses being felt by kernel maintainers.

@sjvn wrote an article about the talk (https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be-cut-as-maintainence-remains-under-strain/) and made a connection between the stable-policy change and the maintainer issue — something I had not done in the talk. It was a bit of a shift from what I said, but not a bad article overall.

Then the rest of the net filled up with other writers putting up articles that were clearly just cribbed from SJVN's piece — sometimes with credit, sometimes without. I'm getting emails about what a terrible idea this all is, as if I had anything to do with that decision or can somehow change it. I have, it seems, taken away everybody's six-year support, and they're not happy about it.

All because of a 30-second mention of a change that was made public something like a year ago. My 1.5 minutes of fame has given me a new appreciation for this old quote from Rusty Russell: "when a respected information source covers something where you have on-the-ground experience, the result is often to make you wonder how much fecal matter you've swallowed in areas outside your own expertise."

My OSSummit EU DAMO talk[1] video is available at https://www.youtube.com/live/ggx9ZssPHU8?si=fP3dinUeJ8pB4KMr&t=16329

The slides are also uploaded to the talk intro page[1] and GitHub[2].

[1] https://sched.co/1OGf9
[2] https://github.com/damonitor/talks/blob/master/2023/ossummit_eu/damo_ossummit_eu_2023.pdf

#linux #kernel #damon #damo #ossummit #ossummit_eu #osseu

@ljs Agreed. I hope fully self driving (a.k.a self-tuning) DAMON be available before that :)

@ljs I'd rather walk until real fully self driving cars be available ;)

@vbabka Thank you! It's a pity that you don't attend OSS, but no problem. I know we will meet in another venue :)

@hyeyoo Trains frequently being delayed. Walking is more predictable ;)

My talk at OSSummit EU[1], which will be held next week in Spain, has accepted.  I therefore arrived in Spain early and walked the pilgrim's road[2], from Burgos to Santiago de Compostella.  After 26 days, I arrived at Santiago de Compostella yesterday.  It was about a 500 km journey.

It is of course the road of pilgrimage, but it was also a journey of DAMON[3] hacking.  I walked in the morning, took a rest and slept in the afternoon and the evening, and then hacked DAMON from midnight until morning everyday.  I had a great time to walk, show, feel, meet, think, and code.

I made a few new friends.  I also made DAMON patches[4,5,6,7,8] that I was working for the last two months without sufficient progress done in time and merged those into the mm tree.  I believe now I can move forward to the next important DAMON feature development.  I also made the first draft of DAMO's new usage document[9], which I was struggling since the DAMO v1.0.0 release.  Hopefully it will cover more DAMON use cases in a stable and convenient way.  What a grateful progress.

The journey is not finished yet, though.  My final destination of this journey is OSSummit EU.  Looking forward to meeting people and sharing some more about DAMON (the talk will be focused on DAMO, though)!


#ossummit #ossummiteu #linux #kernel #damon #damos #spain #pilgrimage #caminodesantiago​


[1] https://sched.co/1OGf9​
[2] https://en.wikipedia.org/wiki/Camino_de_Santiago​
[3] https://damonitor.github.io​
[4] https://lore.kernel.org/damon/20230907022929.91361-1-sj@kernel.org/​
[5] https://lore.kernel.org/damon/20230913022050.2109-1-sj@kernel.org/​
[6] https://lore.kernel.org/damon/20230914021523.60649-1-sj@kernel.org/​
[7] https://lore.kernel.org/damon/20230915025251.72816-9-sj@kernel.org/​
[8] https://lore.kernel.org/damon/20230916020945.47296-1-sj@kernel.org/​
[9] https://github.com/awslabs/damo/commit/615b595e14fc32763c8b34f96d88290ccbd277fc​

damo[1] (DAMON userspace tool)'s GitHub stats at the moment show nice numbers. 111 stars, 10 watching, 20 forks. :)

[1] https://github.com/awslabs/damo

#linux #kernel #damon #damo

Yet another academic paper preprint[1] regarding serverless on CXL using/citing DAMON has uploaded: "Understanding and Optimizing Serverless Workloads in CXL-Enabled Tiered Memory"

[1] https://arxiv.org/pdf/2309.01736.pdf

#linux #kernel #damon

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

@gregkh @krzk I surely understand and agree with many of you, and Greg's points :) I am also aware of the talk and recent maintainers summit discussion. Actually the discussion was one of the major motivations for writing the scripts. https://github.com/sjp38/lazybox/blob/master/cve_stat/report/report.md. Again, I only hope these numbers to be useful for discussions between people having different opinions about CVE, or at least me. Thanks to @gregkh for reminding me the RH case again. That will be helpful for me to discuss with others :)

@krzk I personally agree many parts of your points. But I also know there are many different opinions and believes about CVEs. I hoped these numbers to be no more, no less but only somewhat can help more people to get dry facts that can all agree upon and further make constructive discussions, and therefore shared. I'm sorry if you felt this post in such a way.

Because my airplane was delayed, I played with kernel CVE data, and summarized[1] the buggy and error-full results.

TL; DR: About 95% of CVEs that affect the mainline tree has fixed before those are reported by linux_kernel_cves project. The number was 76%, 69%, 73%, 78%, 83% and 82% for 6.4.y, 6.1.y, 5.15.y, 5.10.y, 5.4.y, 4.19.y, and 4.14.y, respectively.

The worst case time between linux_kernel_cves report and fix commit being fixed was [16, 32) weeks for the mainline. For the stable trees, the number was [4, 8) weeks (6.4.y), [16, 32) weeks (6.1.y and 5.15.y), [32, 64) weeks (5.10.y), [64, 128) weeks for 5.4.y, [32, 64) weeks (4.19.y and 4.14.y).


[1] https://github.com/sjp38/lazybox/blob/master/cve_stat/report/report.md

#linux #kernel #cve #stable #lts

I’m running the Tracing Microconference at Linux Plumbers. If there’s an issue you would like to discuss there, please submit a MC topic. https://lpc.events/blog/current/index.php/2023/08/17/tracing-mc-cfp/

We started running DAMON functionality tests suite[1] for a few kernels including all DAMON-available stable kernels from the early stage of DAMON project. Recently, we further started testing stable-rc kernels and sending[2] the results to stable@. I now feel this is making DAMON healthier. After all, this makes my name listed on the stable kernel version update commit[3] ;) So I would recommend more people to have some fun with stable-rc kernels and take their credit if they want.

#linux #kernel #damon

[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] https://lore.kernel.org/damon/20230809171146.90801-1-sj@kernel.org/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.4.y&id=714a286bf9ee3740260c61471ed72d10bd17336a

One of my unofficial and personal goals for 2023 was to create 100 GitHub stars with the DAMON user space tool (damo)[1], and while I hoped it would be realized at least by the end of 2023, we achieved it much sooner than expected - just one day after our 100th release!

[1] https://github.com/awslabs/damo

#linux #kernel #damon #damo

RE: https://social.kernel.org/objects/2f698624-50d8-43a6-b58a-fa1727ee829c