There are many out-of-tree examples of rust kernel code, but as of right now, none have been merged.
Before Rust starts getting used "for real" in the kernel there's a lot of barriers to overcome. Most maintainers aren't hugely proficient in Rust and absolutely do not have the time to learn. Needing yet another toolchain is annoying (especially when you need bits that aren't in stable yet), anything you write in Rust probably won't get built in distro kernels for a long time, and anything you work on today is hugely uncharted territory since it's all so new.
I think one thing a lot of people don't understand from "outside" the kernel development sphere is that standards for getting stuff upstream are typically pretty high for most subsystems, a lot higher than most open source projects. There are a lot of open questions about Rust in Linux that don't have clear answers, and Linux really struggles with consensus. Yes it has a dictator, but that dictator very rarely dictates anything that hugely moves the needle.
I do think "real" kernel bits written in Rust will get upstream and will get used, but it will be a very slow burn.
But then again as I understand it the spec is so massive and has plenty of problems it may not be something that is improved by rust.
https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e...
https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-98...
The above thread is really strange that they picked such a niche thing in networking to contribute to, as sockets don't have many uses within the kernel itself other than NFS or dhcp or stuff like that. They should have aimed to add things to the QoS layer, qdisc, classifier, whatever, there's tens of those and you can easily add another. Start small.
The problem really is that the people who want to see Rust in the linux kernel have next to no linux kernel background and have a poor understanding of how Linux works and how things are generally done.
Also the people who contribute big things to the linux kernel usually have a clear business case behind them and a big company paying them to work on it full time.
For example I could imagine Microsoft eventually contributing in this regard, say they want some more Hyper-V virtual hardware drivers in Linux and they decided to do that in Rust. They've been lately using Rust in the Windows kernel so it's not that unrealistic to think it may happen.
A filesystem written in Rust would be cool... but it's probably going to have to be a new one rather than a rewrite, I can't imagine people going through the trouble of rewriting btrfs in Rust. And big names like Facebook could actually back that effort.
I really love using Rust for middleware things, however right now I can't convince myself to use it on low level things like OSes or microcontrollers since it seems to be a lot of trouble with getting Rust to play nice with FreeRTOS for example, and there seems to be no production ready rtos written in Rust either.
Core kernel will never have Rust in it, and that is a correct decision. Linux and C have a long history of just working, and there is value in making sure that C code you write is correct and explicitly thinking about memory and what gets modified where. Correct coding is more than just memory safety, and compilers can't check everything for you.