@vegard @kernellogger very cool!

@kernellogger oops, I should have read that in the script, my fault, thanks!

@kernellogger 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''

@kernellogger And the obligatory `perf stat` output:

$ perf stat ~/linux/stable/commit_tree/id_found_in 27e348b221f6
6.3 6.3.2

Performance counter stats for '/home/gregkh/linux/stable/commit_tree/id_found_in 27e348b221f6':

927.17 msec task-clock:u # 2.695 CPUs utilized
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
102,368 page-faults:u # 110.409 K/sec
625,620,707 cycles:u # 0.675 GHz (86.75%)
17,593,408 stalled-cycles-frontend:u # 2.81% frontend cycles idle (74.93%)
244,430,441 stalled-cycles-backend:u # 39.07% backend cycles idle (77.20%)
1,688,567,927 instructions:u # 2.70 insn per cycle
# 0.14 stalled cycles per insn (79.87%)
281,869,777 branches:u # 304.009 M/sec (90.53%)
2,038,670 branch-misses:u # 0.72% of all branches (94.14%)

0.343984835 seconds time elapsed

0.198861000 seconds user
0.661305000 seconds sys

@kernellogger I need speed as I rely on that all the time to determine how far back to backport stable changes, and to determine if any of the pending fixes have fixes of their own that we have missed, or if fixes have ended up in Linus's tree for things we backported in the past. As an example:

$ time ~/linux/stable/commit_tree/id_found_in 27e348b221f6
6.3 6.3.2

real 0m0.336s
user 0m0.261s
sys 0m0.501s

And really, it would be great if I could make that go faster, I played with using ripgrep instead of git grep but it turned out git grep was faster for this use case, and so I gave up as it being "good enough" for now.

@kernellogger Cool, here's a horrible hack of a "implement a database in a filesystem tree" that I use for the stable development work I do for this same problem (and others like it): https://git.sr.ht/~gregkh/linux-stable_commit_tree

@vbabka @llvm That is correct, the AMD entry is back in place, it was my fault, another company was claiming AMD said something that they didn't actually say in a "fun" email thread that I don't want to revisit anymore...

So I presented today on EU CRA, NIS2 and other initiatives to regulate code/hardware/services. One consistent piece of feedback I got is that the amount of upcoming regulation is so huge that even dedicated professionals are unable to keep track of it all. So it is not just me (or you). It is _a lot_. https://berthub.eu/one/EU%20and%20you.pdf

@somenxavier @embeddedrecipes As we have said for decades, "there is no roadmap, Linux is evolution, not intelligent design". Submit changes you want to see happen if you want change, that's what everyone does!

How to fix the TTY layer in Linux?
@gregkh explains at #er2023
https://git.sr.ht/~gregkh/presentation-tty/tree/9afefcf3171a02e5eee19639ec62456511902a56/item/tty.pdf

Slides and recording of @gregkh's great @KernelRecipes talk "#Linux #Kernel security demistified" are now online:

Slides: https://git.sr.ht/~gregkh/presentation-security/blob/3547183843399d693c35b502cf4a313e256d0dd8/security-stuff.pdf

Video: https://www.youtube.com/watch?v=xDHTn0auo2w&t=14975s (that's a section of the live stream) #LinuxKernel

Slides for my @KernelRecipes talk from yesterday for "Linux Kernel security demistified" can be found here: https://git.sr.ht/~gregkh/presentation-security and the video will be probably online sometime "soon" for those that missed the live stream.

@davem_dokebi our godfather on stage for a sump up of netconf 2023 #kr2023

A sign of DisplayPort over USB-C (external display) working with the #mainline kernel on the recently launched #Fairphone 5!

This wouldn't have been possible without the great work done by all the people contributing to Linux and this SoC, especially the amazing people at Linaro!

#postmarketOS #Fairphone5 #LinuxMobile #kr2023 #KernelRecipes

@funkylab @KernelRecipes then read the lwn.net article instead: https://lwn.net/Articles/944300/ There's no lack of information about the CRA out there right now.

@gregkh on stage: Demystifying the Linux kernel security process #kr2023 - serious things coming...

@krzk @corbet @sjvn press releases will never be read by the people that actually need to know this anyway, so we aren't going to go down that path :)

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

@zev @monsieuricon That was my fault, my scripts didn't like the long latency of attempting to send emails while going through the chunnel and so the lockfile expired and decided to spawn a bunch of retries to resend the emails.

I disabled that for the return trip, and all is now good, apologies for the multiple messages, this seems to happen to me every few years...