Please provide a short (approximately 100 word) summary of the following web Content, written in the voice of the original author. If there is anything controversial please highlight the controversy. If there is something surprising, unique, or clever, please highlight that as well. Content: Title: Klint: Compile-Time Detection of Atomic Context Violations for Kernel Rust Code Site: Gary Guo is helping our efforts to bring Rust into the Linux kernel by building a tool called klint . We asked him to provide his perspective on the work in this blog post. Thank you for your partnership and contributions, Gary! For the last couple of months, I have been working on a static analysis tool called klint that is able to detect, in compile time, coding errors related to atomic contexts in Rust kernel code. In this blog post, I'll talk about what is atomic context, what can happen if they are misused, how it is related to Rust and why it is important to detect these errors. Atomic Contexts Generally, a piece of Linux kernel code runs in one of two contexts, atomic context or task context (we are not going to discuss the raw atomic context in this blog post). Code running in task contexts is allowed to sleep, e.g. rescheduling or acquiring a mutex. Code running in atomic contexts, on the other hand, is not allowed to sleep. One obvious example of atomic context is interrupt handlers. Apart from interrupts, the kernel also moves from task context into atomic context if a spinlock is acquired, or when the code is inside an RCU critical section. Sleeping inside an atomic context is bad -- if you acquire a spinlock and then go to sleep, and another piece of code tries to acquire the same spinlock, it is very likely that the system will be locked up. spin_lock ( & lock ); ... mutex_lock ( & mutex ); // BAD ... spin_unlock ( & lock ); These kinds of mistakes are easy to make and hard to debug, especially when the sleepable call is deeply nested. To debug this, kernel C code has might_sleep() annotations all around the place (e.g. inside the mutex_lock function). If you have DEBUG_ATOMIC_SLEEP config enabled, then the kernel will track the preemption count. This counter is incremented whenever you enter an atomic section (e.g. by acquiring a spinlock) and decremented on exit. If the counter is non-zero, then it means that the kernel is inside an atomic context -- calling might_sleep() in this case will produce a warning to aid debugging. Memory Safety Aspects of Atomic Context The Rust for Linux project tries hard to ensure that it can provide safe abstractions of the kernel C API and empower drivers to be written in safe Rust code. We already have a list of synchronisation primitives implemented, and this includes spinlocks and mutexes. Therefore, the concept of atomic context is as relevant in Rust code as in C code. You might ask, how is memory safety related here? If you are familiar with Rust, there's a chance that you are aware of what "memory safety" in Rust means. Safe code in Rust should not be able to cause use-after-free or data races, but causing a deadlock is memory safe. If a Rust kernel driver sleeps while inside an atomic context, it might cause a deadlock, which is bad and should be avoided, but it should be memory safe regardless, right? This would be true if spinlocks were the only source of atomic contexts. However, the kernel very widely employs RCU (read-copy-update). Details of RCU can be found in the kernel documentation , but in a nutshell, RCU is a synchronisation mechanism to provide efficient read access to shared data structures. It allows multiple readers to access shared data structures without locking. A data structure accessible from an RCU read-side critical section will stay alive and will not be deallocated until all read-side critical sections that may access it have been completed. In the kernel, an RCU read-side critical section starts with rcu_read_lock() and ends with rcu_read_unlock() . To drop a data structure unpublished from RCU, one would do synchronize_rcu() before dropping it: /* CPU 0 */ /* CPU 1 */ rcu_read_lock (); ptr = rcu_dereference ( v ); old_ptr = rcu_dereference ( v ); /* use ptr */ rcu_assign_pointer ( v , new_ptr ); synchronize_rcu (); /* waiting for RCU read to finish */ rcu_read_unlock (); /* synchronize_rcu() returns */ /* destruct and free old_ptr */ If you look at the implementation detail of rcu_read_lock() , however, you will see that it compiles down to a single compiler barrier — asm volatile("":::"memory") , if all the debugging facilities are off. Yes, there are absolutely no instructions generated for rcu_read_lock() and rcu_read_unlock() ! Linux kernel plays a trick here -- it implements synchronize_rcu() in a way such that it returns after all CPU cores experience context switches at least once. The kernel considers an RCU read-side critical section to be an atomic context, so no code inside it may sleep and thus cause a context switch. With this reasoning, if all CPU cores have gone through context switches, then all live read critical sections must have been completed. The soundness of synchronize_rcu() relies on the fact that code cannot sleep inside RCU read-side critical sections! If such sleep indeed happens, it can cause synchronize_rcu() to return early and thus cause memory to be freed before rcu_read_unlock() , leading to use-after-free. TL;DR: How RCU is implemented in the Linux kernel lifts sleep in atomic context from "it's bad because it might cause deadlock" to "it's bad because it can cause use-after-free". RCU Abstractions in Rust Rust code, unlike C, usually does not use separate lock and unlock calls for synchronisation primitives -- instead, RAII is used, and lock primitives are typically implemented by having a lock function that returns a Guard , and unlocking happens when the Guard is dropped. For example, RCU read-side critical section could be implemented like this: struct RcuReadGuard { _not_send : PhantomData <* mut () > , } pub fn rcu_read_lock () -> RcuReadGuard { rcu_read_lock (); RcuReadGuard { _not_send : PhantomData } } impl Drop for RcuReadGuard { fn drop ( & mut self ) { rcu_read_unlock (); } } // Usage { let guard = rcu_read_lock (); /* Code inside RCU read-side critical section here */ // `guard` is dropped automatically when it goes out of scope, // or can be dropped manually by `drop(guard)`. } If we disregard the memory safety issues discussed above just for a second, Rust lifetimes can model RCU fairly well: struct RcuProtectedBox < T > { write_mutex : Mutex < () > , ptr : UnsafeCell <* const T > , } impl < T > RcuProtectedBox < T > { fn read < 'a > ( & 'a self , guard : & 'a RcuReadGuard ) -> & 'a T { // SAFETY: We can deref because `guard` ensures we are protected by RCU read lock let ptr = unsafe { rcu_dereference ! ( * self . ptr . get ()) }; // SAFETY: The lifetime is the shorter of `self` and `guard`, so it can only be used until RCU read unlock. unsafe { &* ptr } } fn write ( & self , p : Box < T > ) -> Box < T > { let g = self . write_mutex . lock (); let old_ptr ; // SAFETY: We can deref and assign because we are the only writer. unsafe { old_ptr = rcu_dereference ! ( * self . ptr . get ()); rcu_assign_pointer ! ( * self . ptr . get (), Box :: into_raw ( p )); } drop ( g ); synchronize_rcu (); // SAFETY: We now have exclusive ownership of this pointer as `synchronize_rcu` ensures that all reader that can read this pointer has ended. unsafe { Box :: from_raw ( old_ptr ) } } } Note that in read , the returned lifetime 'a is tied to both self and RcuReadGuard . That is, the RcuReadGuard must outlive the returned reference -- leaving RCU read-side critical section by dropping RcuReadGuard will ensure that references obtained through the read method will no longer be readable. However, such an abstraction is not sound, due to the sleep-in-atomic-context issue that we have described above. fn foo ( b : & RcuProtectedBox < Foo > ) { fn bar ( b : & RcuProtectedBox < Foo > ) { let guard = rcu_read_lock (); let p = b . read ( & guard ); let old = b . write ( Box :: new ( Foo { ... })); sleep (); // `synchronize_rcu()` returns drop ( old ); // Rust allows us to use `p` here // but it is already freed! } There were discussions about how we can provide abstractions of RCU in a sound way in the past two years. One approach is to make all RCU abstractions unsafe -- this is bad from a usability point of view, and