Greg K-H

Public Key

npub1hfelzemwrvxxpd7qqfr3m3a7mv4nmf9ydjdnfk83lj6zuhdqmlmsgkk5ww

NIP-05 Address

Profile Code

nprofile1qqst5ul3vahpkrrqklqqy3cac7ldk2ea5jjxexe5mrcledpwtksdlacpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdvrxer

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1hfelzemwrvxxpd7qqfr3m3a7mv4nmf9ydjdnfk83lj6zuhdqmlmsgkk5ww

Show more details

Last Notes

2026-09-25 13:26:38 GMT

Here's a bit more up to date version of the "how many CVEs have we fixed" stats than what I showed earlier this week at @nprofile…pmw0 as I was able to catch up on some reviews on my way home on the train.
Also cve.org just crossed the 100000 numbering barrier just now, first time that ever has happened, hopefully no scripts broke. And yes, the kernel.org CNA has CVE-2026-100000 reserved, need to find a "good" bug for that one, suggestions welcome!
https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/100xxx
https://media.social.kernel.org/media/de4884b2cd6303ece06715d3c40a0bde7b6176d7bf498a180f8a3f10b15d7f24.png

2026-09-23 14:55:18 GMT

My secret kernel review tools were spotted in the back of the @nprofile…pmw0 room
https://media.social.kernel.org/media/9d2f210065207954b69c79f887e99dea816d6ffc3f11aaa95f66ca6b0ab88e40.png

2026-08-03 13:31:13 GMT

In which I explain how I will treat LLM generated or assisted patches for the Linux kernel drivers/staging/ subsystem going forward:
https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh/T/#u
(hint, not allowed, except for security bugs that you can prove actually fix something by testing the issue on the actual hardware the driver controls.)

2026-07-30 10:43:40 GMT

Another one of those mornings....
https://media.social.kernel.org/media/cc6e6585f88f8afbe368f3ccb36b8033b54f20fe6ccb4f773e81a5591b24fe20.png

2026-07-03 09:35:22 GMT

CVE issue stats for the first 6 months of the year, by vendor, sorted by quantity:
2308 "vendor": "Linux",
1752 "vendor": "Google",
1308 "vendor": "n/a",
843 "vendor": "Microsoft",
495 "vendor": "OpenClaw",
445 "vendor": "Oracle Corporation",
395 "vendor": "Adobe",
340 "vendor": "Red Hat",
310 "vendor": "Apache Software Foundation",
284 "vendor": "Apple",
I gotta change my talk where I say “we are #2” as that’s not the case by far anymore. Hopefully the other vendors get their act together and start properly reporting all CVEs to the system, not just the ones that they feel like submitting…
And the numbers for OpenClaw is quite impressive, nice to see someone take responsibility there :)

2026-04-23 12:34:44 GMT

- reply

@nprofile…mcwl Been there, done that, gave up as I just want to get real work (i.e. kernel stuff) done faster.

2026-04-23 12:12:17 GMT

After totally messing up my gdm configuration by foolishly using `gdm-settings` (I didn't want the machine to suspend at the login screen for obvious reasons that doesn't play well with logging into it from other boxes), causing it to not properly even show a login screen, I've reverted back to running plasma and realizing it's been a long time since I last ran KDE and how nice it's gotten since then.
So, until I figure out how to wipe all gdm settings from the system (hint, I tried the "reset" option on gdm-settings and to blow away all dconf files that i could find on the disk, but odds are I missed something), I guess I'm now a KDE user until I move to a new system...

2026-04-06 10:21:26 GMT

Dear semi-lazyweb,
Given a git diff of a C/Rust codebase, how to best determine which functions/defines have been modified between the two versions? Yes, the diff itself sometimes gives hints as to what has changed, but it's not always correct. Think about when it modifies the start of a function, but the diffstat "name" shows the previous function, a correct marking, but not what is needed.
Is the correct answer really going to be "compile the two versions and compare the AST" or something like that? No "diff library" somewhere that "knows" how to parse C (and Rust) that can do this in a faster way? Surely I'm missing something obvious here...

2026-03-31 13:47:55 GMT

In a few minutes I get interviewed by Shuah Khan and might answer questions from the audience if we have time: https://www.linuxfoundation.org/webinars/lf-live-maintainer-series-my-life-as-a-linux-kernel-developer-and-maintainer-with-greg-kh-and-shuah-khan
It will be recorded for playback later as well. It's part of the great Mentorship video series that Shuah has been putting on for years, the back catalog is deep: https://events.linuxfoundation.org/lf-live-mentorship-series/

2026-03-30 06:49:43 GMT

We've gotten five different "security reports" about the decades old USBIP protocol https://docs.kernel.org/usb/usbip_protocol.html and how it is "insecure" in the past few days.
Yes, it's only to be run between "trusted" devices, and we will gladly take patches so see the ones recently posted to the linux-usb mailing list to mitigate these issues, but this is very strange as to why all of a sudden this is being reported all at the same time by random different semi-anonymous accounts.
Is there some big usb-over-ip installation somewhere that people suddenly started caring about out there, or did some internal hacking tool that uses usbip just get leaked?
No one who we asked "why?" when they submitting these issues would give a very clear answer to that simple question so something is going on...

2026-02-16 21:14:08 GMT

It was one of those Mondays...
https://lwn.net/Articles/1059031/

2026-02-16 13:54:59 GMT

Another post in my series about the kernel CVE process, all about how we classify fixes to be assigned a CVE and other related things:
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

2026-02-07 09:19:25 GMT

- reply

Curiosity got the best of me, and I clicked on the links and this just looks like an OpenAI "sales funnel", which is pretty hilarious when you consider the target was open source security teams, none of which could ever fill out these types of forms without flat out lying.
https://media.social.kernel.org/media/f7f1abceeee80be2c20f2cc9c7627bcfaabf0cd7d633943e8398eda9b01c928c.png
https://media.social.kernel.org/media/7fce90303bcec67754efdbbde3311f5ec0aac638079e73574bcd53b1850b1b72.png
https://media.social.kernel.org/media/8e039ceb12737a0bbcf847b9750c843ac69bad208a4e2004499d798746f609e8.png
https://media.social.kernel.org/media/5141ce257a441147e7b26ae6ca74ab6308c9cc97f4334d4852ffd6a40b112a05.png

2026-02-07 07:35:41 GMT

Looks like the AI companies have finally run out of money as they are asking various open source projects to test their closed source products for them for free. What could go wrong with giving access to an unknown tool to private code repos?
If I didn't know better, I would think this is an elaborate phishing scam, or they have run out of data to scrape and need more training material.
Gotta admire their brazenness...
https://media.social.kernel.org/media/84807b046eac8f56458134f8cb702bb885ab16f63dcba00cc758701a35e79ac7.jpg

2026-01-30 08:48:33 GMT

Prediction for the potential future:
When the AI coding agent companies are just about to run out of money, down to their last few % raised as none of their customers are actually paying the real cost required to run these services, they pivot and take all of the uploaded code that was willingly sent to them, turn it into thousands of products / services to sell / rent, disconnect the public api endpoints leaving their old customers helpless as they no longer remember how to program "in the raw" and can not understand their own codebases, and compete directly against them putting their own customers all out of business which finally results in a positive income stream and "validation" of the coding agent companies previously over-hyped business valuations.
"But copyright law will prevent this!" you say...

2025-12-30 14:36:47 GMT

All 5960 GSD kernel security reports are now finally processed and CVE ids have been assigned for those that meet the cve.org criteria. Only took me almost 2 years of manual review, ugh, that was a grind:
https://lore.kernel.org/r/2025123055-directory-hemlock-a282@gregkh

2025-12-28 12:29:17 GMT

The kernel CNA assigned their 10000th CVE last week, CVE-2025-68750
So far the “stats” look like:
Year Reserved Assigned Rejected A+R Returned Total
2019: 0 2 1 3 47 50
2020: 0 17 0 17 33 50
2021: 0 732 24 756 16 772
2022: 3 2041 47 2088 0 2091
2023: 1 1464 47 1511 0 1512
2024: 6 3069 96 3165 0 3171
2025: 73 2421 39 2460 0 2533
Total: 83 9746 254 10000 96 10179
Note, the “year” is the year the bug was fixed in the kernel tree, NOT the year the CVE was applied for/assigned.

2025-12-16 16:09:42 GMT

Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase.
That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.
Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.

2025-12-09 04:43:28 GMT

Starting to write up a series of articles about the Linux kernel CVE work that has happened in the past 2 years, starting with some "back to basics" information about how Linux kernels are numbered as many people/companies really don't know how we do this, and it matters a lot in tracking bugfixes and how to determine "vulnerable" and "fixed" kernel releases:
http://www.kroah.com/log/blog/2025/12/08/linux-cves-more-than-you-ever-wanted-to-know/
and
http://www.kroah.com/log/blog/2025/12/09/linux-kernel-version-numbers/

2025-12-03 13:10:46 GMT

The European Union has now published a great page about the Cyber Resilience Act that contains a 66 page FAQ about lots of things in "plain english": https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation

2025-12-03 12:58:24 GMT

The last 5.4.y kernel release has now happened: https://lore.kernel.org/all/2025120319-blip-grime-93e8@gregkh/
Please don't use this branch anymore, it's really old, and pretty obsolete, and has over 1500 unfixed CVEs in it:
https://lore.kernel.org/all/2025120358-skating-outage-7c61@gregkh/
And if you are stuck with that kernel version for some reason, go ask your vendor to fix those 1500+ CVEs, otherwise you are paying for support that doesn't actually do anything for you...

2025-11-21 14:46:41 GMT

It has now been 0 days since a AI-hallucinated "security report" was sent to the kernel security team.
Right now we seem to be averaging about 1 per week, not bad overall probably compared to other projects.
To be fair, a real security bug was recently found with an "ai tool", but the authors of that at least took the time to verify it was real before sending it to us, and they provided a patch, so not all is doom and gloom.

2025-10-01 20:38:57 GMT

Benchmarking the different machines in my office with the wonderful kcbench: http://www.kroah.com/log/blog/2025/10/01/the-only-benchmark-that-matters-is.../

2025-07-29 06:07:38 GMT

Looks like the risc-v community is learning from history! Hopefully this results in more upstream development efforts: https://riscv.org/blog/2025/07/risc-v-upstreaming/

2025-07-15 08:42:55 GMT

Days since an "AI found security bug" turned out to be totally false due to the inability of the tool to actually parse C code: 0
I'm seeing multiple of these type of "reports" per week now for Linux. Why do people think that an LLM can somehow do better than a compiler and also not even test their proposed changes to verify they even do anything?
{sigh}

2025-07-10 12:25:16 GMT

The second hardest thing in working in an open source developer community is learning who to ignore, be it in patch reviews or other places.
The hardest thing in working in an open source community is realizing that you are the one that everyone is ignoring.

2025-06-08 07:51:27 GMT

Long and fun interview with me on the Wookash Podcast just got published: https://www.youtube.com/watch?v=-1-OjxPJZcs

2025-06-04 07:58:37 GMT

My seat name tag for the EU CRA meeting today...
https://media.social.kernel.org/media/1cf2ce6ef522658d5cb63bc5f08aea5490eaf1e358ee6e7b42cb290c17dbf3db.jpg

2025-04-16 07:14:12 GMT

Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.

2025-03-19 21:16:04 GMT

Fun, but long, interview with me about how the Linux development process works was just released: https://newsletter.pragmaticengineer.com/p/how-linux-is-built-with-greg-kroah
It's not all boring, I talk about Rust and our lack of project managers (both good things IMO) so there's lots for people to be grumpy about if you are so inclined.

2025-02-26 10:54:12 GMT

Perl is now a CNA, able to assign their own CVE ids, this is great news!
https://security.metacpan.org/2025/02/25/cpansec-is-cna-for-perl-and-cpan.html
Just in time for my talk about this very topic in a few weeks about how all open source projects should be doing this:
https://lfms25.sched.com/event/1urXE/take-control-over-your-projects-cve-entries-before-someone-else-does-greg-kroah-hartman-linux-foundation

2025-02-14 15:36:34 GMT

While I don't know if is the first time this has happened, it's good to acknowledge this given all the crazy, odd, and incorrect press about Rust in Linux these days.
A new in-kernel api just landed in linux-next from my tree and should hopefully show up in 6.14 to make some kinds of drivers easier to write, that has a rust binding added at the exact same time:
https://lore.kernel.org/all/2025021023-sandstorm-precise-9f5d@gregkh/
Many thanks to Lyude and Danilo and many other Rust kernel developers for the help in creating the binding and make the C side work well for both Rust and C code at the same time. The end result here for any C developer alone, is much better off for all of their help.

2025-01-31 09:22:52 GMT

For 2025, here is a updated and 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 still get on a weekly basis:
- The Linux 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 number of organizations that fail to understand this is way too high.
- The kernel community DOES assign CVEs, as we are a CNA, please see https://www.kernel.org/doc/html/latest/process/cve.html for how they are handled and assigned. Side note, we were #2 in quantity for CVE assignments in 2024 despite only doing so for 10 1/2 months, averaging about 10 CVEs per day. Any process you might have where you feel you need to research each CVE on an individual basis manually is going to be a major time suck, automate it! All CVE entries are provided with proper git commit ids for the vulnerable release ranges for you to check yourself, AND we have tools and other formats that you can use to check this yourself. See https://git.kernel.org/pub/scm/linux/security/vulns.git/ for the tools and raw data for you to pull from directly if you don't want to deal with the cve.org json feed.
- Kernel CVE entries are constantly updated over time, you can not just look a them only when created, and then ignore all updates. Too many groups are missing revoked CVE entries and tightening of vulnerable kernel ranges that we are updating on a weekly basis. By ignoring the updates, you are causing yourself more work, not less. cve.org provides an "updated" feed in their git tree, use it!
- Along the lines of the huge number of recorded CVEs, 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.

2024-12-17 09:08:33 GMT

- reply

@nprofile…lrh8 @nprofile…qfqs Maybe, maybe not. Please see my old post here: http://www.kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/ for what drives all of this (hint, people actually asking that they need it AND providing the help to make it possible.)

2024-12-07 11:48:51 GMT

"I'm probably not alone in thinking that sometimes the compiler writers are doing their hardest to make life hard for people writing low level code." -- David Laight at: https://lore.kernel.org/r/[email protected]
It's a fun thread, recommended for anyone who deals with compilers and trying to get them to do what you would think would be a "easy" thing to do and the hacks around them to get them to do that (hint adding "+ 0" to an expression tricks the compiler into doing what you meant it to do is usually a sign that something is wrong somewhere...)

2024-12-05 11:45:14 GMT

The last 4.19.y kernel has been released:
https://lore.kernel.org/lkml/2024120520-preorder-untracked-6e5b@gregkh/T/
Please move to a more modern kernel if you are somehow still running this one, which I strongly would not recommend doing.

2024-12-04 13:58:22 GMT

New hardware showed up today, turns out Linux works just fine on it. Here's the 6.12.1 kernel running in Wayland.
Water bottle for scale.
https://media.social.kernel.org/media/c23c0efac6d5a5d00f885c30634469831efed2e9c97b87d697aa22265cc0f847.jpg

2024-11-16 07:41:41 GMT

- reply

@nprofile…5k85 Odd, works for me!
How about this https://github.com/gregkh/usbutils/security/code-scanning
And it's obviously picking up the temp files that meson uses for "does this compiler have this feature" but that's temp files, and not actually in the repo itself. Surely tools like meson are handled properly, right?

2024-11-16 07:38:33 GMT

Dear lazyweb,
For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.
Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.
Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...
So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?

2024-09-02 19:13:49 GMT

Finally converted usbutils over to meson from autotools. Odds are I messed something up, so I should do a release soon to see what broke in the distros as I have no idea how they package this thing anymore:
https://git.sr.ht/~gregkh/usbutils/commit/86dcab8964901d15b87b156546559c8ae28bd9fe

2024-02-27 05:34:06 GMT

- reply

@npub1qtj…wqns @npub1cm7…32y8 We've been on irc for decades, we are everywhere :)

2024-02-25 13:43:26 GMT

- reply

@npub1cm7…32y8 Your data is going to be a bit skewed here, we have ONLY processed the v6.7..v6.7.1 and most of the v6.7.1..v6.7.2 commits so far for CVE-related stuff, which by far the majority have only Fixes: tags due to my travel schedule during those releases (i.e. I didn’t have the cycles to catch up with the cc: stable@ tagged commits. I bet the numbers will level out over time as we catch up with the rest of the commits in the v6.7.Y releases.
And it’s good to see people paying attention, thank you!

2024-02-14 08:13:19 GMT

- reply

https://lore.kernel.org/lkml/2024021430-blanching-spotter-c7c8@gregkh/ is the v3 version of the kernel CVE process documentation patch, which should address a number of reported issues in the first version (v1 suffered from being an older version, my fault.)

2024-02-13 19:07:26 GMT

Linux is now a CNA: http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/
This has taken a long time, I'd like to thank all the groups that helped, and especially the CVE group themselves. Our application was a bit different than other groups, but they understood that this is important for security overall.

2024-01-10 14:48:05 GMT

The 4.14.y kernel tree is now end-of-life: https://lore.kernel.org/all/2024011046-ecology-tiptoeing-ce50@gregkh/
It's been a good 6 years, and it was a solid kernel version for its time, but anyone still using it should have moved off it a long time ago as it has been showing its age for quite a while.

2023-11-15 17:36:25 GMT

- reply

@npub1cm7…32y8 Yes, that's why the dates are like this.
And I just realized, we never publicly said anything about "2 years support for LTS", the kernel.org page has always had longer dates, all we said was "we will not be doing 6 years anymore".
So no one actually looks at the documentation we write (i.e. the web page), AND I didn't even remember that we had written that back in February of this year, this feels like a "write once, read never" type of file...

2023-10-30 08:37:42 GMT

This came up in a private thread about a kernel patch review where the contents were created with an "AI" tool, so I figured I might as well put it somewhere a bit more public as people don't seem to really understand the issues involved:
My policy is that I do not take any output of any "AI" tools unless the providence of the data that was used to feed the AI tool can be proven to be under the proper copyright rules as to be compatible with the GPLv2 license.
So in other words, nothing from chatgpt at all, that's obviously full of copyrighted works that are not allowed to be reused in this manner.

2023-10-30 06:30:36 GMT

- reply

@npub1cm7…32y8 @npub17e2…qj4x It's on the front page now, took a bit for the signed tag to propagate due to timezone differences...

2023-10-06 09:16:07 GMT

- reply

@npub1cm7…32y8 Let's debug by this horrible interface!
$ ./linuxscru history Makefile
Traceback (most recent call last):
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 526, in <module>
cmdargs.func(cmdargs)
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 376, in cmd_history
if not GITTREE.is_file(cmdargs.patterns):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/fast_t2/linux/gregkh/./linuxscru", line 251, in is_file
if GITTREE.gitpyrepo.git.rev_list('-1', GITTREE.remotes['mainline'][0], '--', pattern):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 739, in <lambda>
return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 1315, in _call_process
return self.execute(call, **exec_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/git/cmd.py", line 1110, in execute
raise GitCommandError(redacted_command, status, stderr_value, stdout_value)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git rev-list -1 mainline/master -- Makefile
stderr: 'fatal: bad revision 'mainline/master''

2023-08-29 09:50:57 GMT

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...