I had an amazing time last week at @KernelRecipes 10th edition. This marked my fifth year speaking at the most unique Linux kernel conference in the world. I'm thrilled to have been a part of this incredible event for half of its life so far. Thank you folks!🐧🙂

Trimmed diffstat of v6.6-rc1 pull request ARM SoC changes from @arnd - the most active platforms for v6.6:

18.9% arch/arm64/boot/dts/qcom/
0.6% arch/arm/boot/dts/qcom/
1.0% drivers/soc/qcom/
...
9.6% arch/arm64/boot/dts/freescale/
3.6% arch/arm/boot/dts/nxp/imx/
0.7% arch/arm/boot/dts/nxp/ls/
0.9% arch/arm/boot/dts/nxp/mxs/
...
8.1% arch/arm/boot/dts/aspeed/
...
8.2% arch/arm64/boot/dts/ti/
0.5% arch/arm/boot/dts/ti/
...
6.6% arch/arm64/boot/dts/nvidia/
...
6.3% arch/arm64/boot/dts/rockchip/

Way to go Qualcomm SoC community!
Source: https://lore.kernel.org/all/4f60d13e-f060-491a-88c7-6f25323a48f8@app.fastmail.com/

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

PSA: don't get COVID. It sucks.

Introducing Bark! Low-latency multi-receiver live-sync lossless audio streaming for local networks. It's like Sonos, but open source, so nobody can brick your devices remotely. It's also written in Rust :)

It sends 48khz uncompressed float32 data over UDP multicast. It can achieve playback sync to within hundreds of microseconds in ideal conditions, and usually to within a millisecond.

I've been working on it in my spare time over the past week, and I'm pretty happy with how it's shaped up. I have three receivers setup and it works remarkably well at keeping everything in sync as I walk around my house. For now it only really works on Linux, and supports Pipewire (and Pulse in theory), but there's no huge impediment to making it truly cross-platform.

It also features a fancy live stats subcommand, which can used on any computer in the same multicast domain to watch the status of the stream cluster:

What do y'all think of non-code contributions, in particular for open source projects?

(E.g. documentation, testing, tooling, bug reproduction, advocacy ... just to list a few!)

Please boost for reach <3

(Answers edited to be shorter and show correctly on all devices.)

The best way to truly support my work on #curl, is to make your company pay for a support contract: https://curl.se/support.html

I work full time on #curl for wolfSSL. Support customers make me get paychecks. Paychecks let me buy food. Food makes my family happy. A happy family lets me do more #curl. More #curl benefits ... well, you.

GCC 14 is still in development, but it has a wonderful new feature in its static analyzer (-fanalyzer).

It can now draw beautiful Unicode diagrams showing exactly how you went out-of-bounds.

See https://inbox.sourceware.org/gcc-patches/20230531180630.3127108-1-dmalcolm@redhat.com/ too.

Thank you to the wonderful David Malcolm for implementing this - who also does a tonne of work with mentoring for GCC's GSoC programme, and working on docs to help new people get into GCC: https://gcc-newbies-guide.readthedocs.io/en/latest/index.html.

@gnutools

# v6.4 linux-riscv recap thing

Round 3 of these "recap" things. I've found them to be both useful and fun to
write - with a couple of months gone by since this stuff actually got merged by
Linus, it is easy to forget it all!

Starting the SoC support side of stuff again, since that's seemingly the
pattern I have set for myself, v6.4 didn't really see all that much in terms of
the SoCs that were already supported. Some minor changes for both the PolarFire
SoC and Allwinner D1 landed, but nothing interesting.
The main change was the addition of support for the StarFive JH7110 & their
first-party VisionFive 2 SBC. Drivers have been merged so far for pinctrl, clk
reset & mmc - enough to boot a basic system to a console.

On the architectural front though, it feels like it has been a busy merge
window. Looking at Palmer's tree before the merge window opened, it looked like
there was more new content in there than we'd had for the last few releases.
Hopefully that's more than a feeling, but rather a "symptom" of having some
more people contributing reviews and patchwork/automated test becoming more
useful.

A change that will be helpful to those who implement their own RISC-V CPUs as a
hobby or learning experience, support was added for 32-bit kernels without an
MMU. In terms of code, there was little to change, but it is yet another niche
combination that is unlikely to be tested much by developers.

A long-running series that was merged in Palmer's first PR for v6.4 was generic
entry support. This means RISC-V now uses the common, cross architecture code
for entering the kernel during syscalls.
TODO: Bjorn, help.
Guo Ren pushed this effort over the line, with Jisheng Zhang contributing some
patches in that series too. Björn Töpel had a hand in things too from a review
point of view, and in fixing things when we discovered systemd was broken after
the series was applied!

Qinglin Pan's Svnapot support series landed too, Svnapot being the ability to
use naturally-aligned-power-of-two page sizes. I don't know of any actual
systems that support this extension, but perhaps Institute of Software Chinese
Academy of Sciences (ISCAS) have something in the works there.

Palmer & his Rivos colleague Evan Green introduced a new "hwprobe" syscall.
This syscall uses key-value pairs to probe for both things like misaligned
access support & what extensions are available on a platform.
"Just use the ISA string" you might say, but unfortunately some backwards
incompatible changes there prevent it from being sufficiently reliable for
use in the userspace API or ABI.

Drew Jones and Alex Ghiti were the most active developers this time around,
with Alex mainly working on "mm" type things & Drew on extension support for
Zicboz and other cleanups.
Alex's 16 changes included support for setting the paging mode from the command
line, for a 64-bit relocatable kernel & a rework of RISC-V's KASAN support.
The relocatable kernel is a pre-requisite for enabling KASLR & involves creating
a special bit of the kernel that is is effectively a copy of some kernel
commandline (and therefore FDT) parsing functions that is without the various
instrumentation etc that will figure out whether to relocate the kernel or not!
I *think* the latter should allow the syzkaller fuzzer to start working again
for RISC-V. I hope that it doesn't trigger a deluge of problems!
Drew added support for the aforementioned Zicboz extension. Zicboz is comprised
of a single instruction, used to zero a cacheblock, which Drew has used to add
an optimised routine for clear_page(). Along the way, he contributed a rake of
cleanups for the scaffolding surrounding ISA extensions.

Vector has once again missed the merge window, although this time around it was
tantalisingly close, with some of the Rivos folk theorycrafting a situation,
involving userspace scheduling, where we would have broken userspace
compatibility. The fix should be straightforward, so hopefully it makes it for
v6.5!

The second PR of the merge window was minimal, mostly containing a few fixups
for the hwprobe series & other compilation issues. The only feature in the PR
was by StarFive's Sia Jee Heng, adding support for hibernation/suspend to disc.

Speaking of hibernation, issues with that patchset interacting with another
that reworked how we map memory lead to hibernation support being locked behind
the "NONPORTABLE" config option. "NONPORTABLE" is used for options that may
result in a kernel that will not work correctly on cross platform basis.
Specifically here, OpenSBI dropped the "no-map" devicetree property from the
reserved-memory nodes it uses to communicate its PMP protected regions to
supervisor-mode software. Thanks to the changes in how we map memory, the first
2 MiB of memory (where OpenSBI typically resides) is now visible to the kernel
and when it tries to hibernate will access the PMP protected region.
There were quite a few mails back and forth about how to deal with this. The
naive (like me!) would think that if firmware wants to protect itself it should
use "no-map". An RFC patch has been sent to change how all archs handle reserved
memory in the face of suspend etc & we shall see where that goes, but for now
hibernation has been marked non-portable & only for use with systems that
actually protect their reserved regions!

The other thing that has occupied time during the release candidates is dealing
with some of the fallout from enabling relocatable kernels. Early alternatives,
alternatives being our way of patching/modifying the kernel at runtime to work
around errata/differences in extension support, sit in a weird spot where they
are called from pre-mmu C code and need some special treatment. In v6.4-rc1,
with the relocatable kernel support, systems with early alternatives would fail
to boot. The interim fix for this is just building such files with -fno-pie, but
that is going to be very fragile and needs a real fix. Unfortunately the real
fix for this does not seem to be straightforward - one proposal is to relocate
once, in physical memory, do early alternative patching and then relocate
again to the final (virtual) memory addresses. Ouch. The other proposal is to
split out these early alternatives & build them into the section of the kernel
that controls the relocations. Neither sounds particular fun to me...

Why is it so much easier to talk about bugs/issues than about features?!?

Plan on submitting a topic to one of the microconferences at Linux Plumbers? Read this blog on what an ideal microconference submission is. https://lpc.events/blog/current/index.php/2023/06/26/the-ideal-microconference-topic-session/

Real-time and Scheduling Microconference CFP https://lpc.events/blog/current/index.php/2023/06/20/real-time-and-scheduling-microconference-cfp/

RISC-V Plumbers Microconference just got accepted: https://lpc.events/event/17/abstracts/1440/

Thanks to @jstultz for showing that the monstrosity of USB A-C-A with a magnetic C connector in the middle actually works! Saves me constantly having to plug/unplug my microphone and camera every other day into my well-worn USB hub.

John did it much better with one less adapter than I so this stack could be smaller if needed, but this is all I could find locally.

Don't usually like talking about things I've done, _but_ v6.5 should contain a "soc maintainer handbook" that I've written. My naive hope is that it is at least a help towards getting people going with maintaining the new platforms that are popping in RISC-V land.

https://lore.kernel.org/all/20230606-escapable-stuffed-7ca5033e7741@wendy/

https://lore.kernel.org/all/20230518131013.3366406-1-guoren@kernel.org/

Vector uABI thread on sw-dev: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/9CI304vHtMo

Atish is trying to figure out why we're getting some many excessive bounce issues recenty.

This is a regular reminder that Russian military is still dropping high-yield explosives onto Ukrainian homes, killing women and children.

This is not f'n okay.

Apparently the reason my internet's been so flaky lately is because a squirrel has been chewing on my fiber.

# v6.3 linux-riscv recap thing

For v6.2's release, I had to go back and dig through the PRs to figure out what had changed in the
release, so I figured for v6.3 I would try and keep on top of the PRs as they went out.
So here's one I prepared earlier I guess!

Perhaps the biggest change for v6.3 is the addition (finally!) of the devicetrees for the various
Allwinner D1 based platforms. There's been a bunch of people involved in that support, including
Heiko who worked on the T-HEAD cpu support, but Samuel Holland did the lions share of the work on
the Allwinner parts of that. I think Arnd pointed out that that amounted to 10 boards?
(Reading this back now, feels like they've been in far longer!)

Bit of business-as-usual for the other vendors, a new dev board for Microchip and some minor changes
on the Renesas stuff now - a negative diffstat actually, as some /delete-node/ macros were removed
from the devicetree as support arrived in drivers for the RZ/Five.
Across the kernel, the bits of support for the JH7110 have started to land, including the mmc,
pinctrl and pmu (that being power management, not perf) drivers.

As for architectural changes in v6.3, things mostly centred around text patching and the handling of
extensions, with work from Heiko Stuebner & Jisheng Zhang *dominating* the first RISC-V PR[0] for
the merge window.
Firstly, Jisheng overhauled how we handle enabling extensions. Since a kernel must be able to run
on all hardware, regardless of what (additional) extensions it supports, we need to enable that
code at runtime. To do so in an efficient manner, we patch the kernel at runtime, during early
boot[1]. This mechanism is called "alternatives" Previously, we stored the absolute addresses of the
"standard" code & the extension's replacement version of that operation, and Jisheng converted that
to use relative addresses instead. All that work, in a complex corner of the kernel (IMO!) just so
that we can use ISA extensions properly in the VDSO!
They also squeezed in some cleanup of our linker script into their schedule somehow..

Heiko then had another big patchset, refactoring extension handling with the aim of allowing
function calls in these "alternatives", so that we can use the Zbb bit manipulation extension in
string comparison routines. Zbb is present on the StarFive JH7110, so, once the devicetrees & clock
drivers etc land for that platform you can go test it out if you have a VisionFive 2.

Unfortunately between those series, a lot changed and the inevitable bugs surfaced, the most serious
of which (preventing boot, mounting a rootfs etc) were fixed before -rc1 by Samuel and Björn Töpel!

Other than those, the first PR also featured:
- Ftrace optimisations from Guo Ren, the first couple patches from a larger series he has been
working on for some months.
- A fix from Andy Chiu, that's been in the works since Linux Plumbers, that caused panics in ftrace
relating to disabling preemption.
- Another one that's been in the works since Plumbers, RISC-V previously had a mix of SOC_ and ARCH_
symbols for vendors, depending on whether a vendor had prior support in other architectures. There
are now ARCH_ versions of the SOC_ symbols as part of an effort to gradually convert everything to
ARCH_ to match what is done in other parts of the kernel.
- Splat decoding support for RISC-V in the decodecode script, from Björn Töpel.
- Sergey Matyukevich upstreamed part of a fix for a tricky looking cache update bug, that seems to
occur on uniprocessor systems running CONFIG_SMP=y kernels.

In the netdev PR, which is where bpf patches for RISC-V (and other archs) get into mainline, Pu
Lehui landed support for both the bpf trampoline and 64-bit kfunc support. Björn seemed pretty happy
about that, so it must be important!

The second PR, as might be expected, was substantially smaller. It did bring with it a KASAN rework
from Alex Ghiti, aiming to substantially simplify what he described as RISC-V's "intricate"
implementation and a bump in COMMAND_LINE_SIZE that should allow syzbot to start fuzzing RISC-V.

In terms of fixes, we got yet another round of fixes for handling the (highly frustrating) decision
to move the csr and fence.i instructions out of the I extension, specifically for mixed toolchains
where some components pre-date that move.

As of -rc3, the most interesting fix this cycle was from Sergey Matyukevich, reverting some
ill-fated changes of his for flushing stale TLB entries and replacing them with another fix.
As far as I can tell from reading the patches, the issue was mainly hit on uniprocessor systems
running SMP kernels - at least the drawn out discussion certainly featured discussion of that
configuration!

Nathan Chancellor took over a bit of work I was doing, the nth patchset of late that has to deal
with the fallout of RVI's decision to move some instructions out of the base I extension.
Great craic really.

A fairly "major" fix for how late in the game it came was Alex Ghiti's conversion of RISC-V back
to using the fixmap for dtb mapping. It was moved out of the fixmap in 2020, with the logic that it
was not actually needed & wasted a lot of space.
However, I ran into some issues where either:
a) reserved memory node names would use "early" virtual
addresses (and thus cause a panic when accessed in a driver)
b) reservation was done too late to prevent early memblock allocations being done in a section of
reserved memory. This would cause the reservation to fail, a bit of an issue if that memory is
not actually usable by the kernel...
The most straightforward thing was to just move back to using the fixmap & sidestep the issue.
Thanks to Alex for doing something promptly & saved me significant time flailing around if I had had
to do it myself!

Of course there were a bunch of other various fixes, with several focusing on different bits of TLB,
and some for the text patching code that had recently been changed by Jisheng et al.
One of those fixes being because somehow we all forgot that the aforementioned alternatives
framework is not always enabled, and if it wasn't the FPU could not be used!

0 - https://lore.kernel.org/all/mhng-9df18be9-c02d-41f8-93ee-7e1e124a31ec@palmer-ri-x1c9/
1 - We also do it when modules are loaded