Huh. So it's only for adding support for the Rust language? Is it about adding support for running kernel syscalls and other in rust?

The goal of the Rust-for-Linux project is to make it possible to implement kernel components in Rust and having Rust be an accepted and supported choice to do so inside the upstream kernel - and for people to use that support of course. It's expected that this is primarily going to be used for driver development, at least at first, since it's quite useful there, it is something where new wholesale components are being written, and the limited compiler/platform support is acceptable. Replacing existing components, especially any core parts of the kernel, is not part of any outlined plan or roadmap.

There are no current initiatives to start porting portions of the kernel into Rust wholesale. The recent Rust support was merely giving Kernel developers the option to use Rust in situations where memory safety might be preferred.

Isn't memory safety needed in all cases?

Not really. There are a lot of things we can do fairly reliably without guaranteed memory safety, and the danger-zones that do exist are pretty clearly mapped and well-known to kernel devs. There are also a lot of things that do need memory safety, but the architecture is usually designed to minimize UB and keep things simple as possible. If you manage to segfault a modern Linux kernel, you're probably using extremely unsupported hardware.

Rewriting Linux in Rust is veritably impossible anyways. It would require re-reviewing over 3 decades of kernel contributions and locking down high-quality 1:1 replications of the previous code. It's just not going to happen, at least not while the standards for merging to the kernel is so high.

The current plans only go so far as to supporting in-kernel device drivers in rust. It will be quite a while if ever before core parts of the kernel are written in rust.