#Linux #kernel 6.6 is out: https://lore.kernel.org/all/CAHk-=wiZuU984NWVgP4snp8sEt4Ux5Mp_pxAN5MNV9VpcGUo+A@mail.gmail.com/

"""So this last week has been pretty calm, and I have absolutely no excuses to delay the v6.6 release any more, so here it is. […] Linus"""

For an overview of new features, check out the two #LinuxKernel 6.6 merge window articles from @LWN or the Kernelnewbies summary:

https://lwn.net/Articles/942954/ and https://lwn.net/Articles/943245/

https://kernelnewbies.org/Linux_6.6

@kernellogger @LWN It's on the front page now, took a bit for the signed tag to propagate due to timezone differences...

@jarkko @conor drivers/staging/ is for code that is abandoned by companies and the community needs others to clean/fix it up, it is not for "code just not ready to be merged yet" as it ends up taking more work to get code out of staging into the real part of the kernel than to just do the real work to start with out-of-tree and then submit it to the proper location.

In other words, drivers/staging/ is not a dumping ground for experiments :)

Just do it right, and get it merged upstream correctly.

And why 5.19? That's a long obsolete and insecure kernel version, no one should ever still be using that mess, especially anything purporting to have anything to do with "security" in any form.

Not a tragedy: "The greatest value that #opensource foundations bring is the creation of a neutral collaboration hub for everyone participating in, and taking a dependency on, a project."

https://www.linuxfoundation.org/blog/how-open-source-foundations-protect-the-licensing-integrity-of-open-source-projects

https://www.centerforcybersecuritypolicy.org/insights-and-research/joint-letter-of-experts-on-cra-and-vulnerability-disclosure A good letter to the EU governments about why the CRA isn't going to be good for vulnerability disclosure as-written. It's nice to see this portion of the CRA finally getting some exposure.

TIL there is an ISO standard for security vulnerability disclosure. First version was made final in 2014, latest version in 2018. Despite actually working in this area for 20+ years, I only now hear of this, yet can't actually see it due to crazy ISO document rules {sigh}
https://www.iso.org/standard/72311.html

@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