# Meeting 2022-10-11

## Mitigations (Peter's [email](https://lore.kernel.org/lkml/[e-mail]/))

Boqun: We do not want the 6.1 kernel with Rust support to be exploited with a known attack.

Miguel: Let's get Peter in contact with the person who is responsible for mitigations in Rust

Miguel: will write answer to Peter.

Wedson: In favor of letting Peter wait.

## `syn`

Benno: When will this be merged?

Miguel: This can be merged anytime, but that will not mean that it goes upstream.

Gary: We do not want to diverge `rust-next` and `rust` any more.

Wedson: working on making `rust-next` and `rust` not divergent.

Wedson: Let's not show the ugly solution, take the good solution immediatly

Benno: I like that, C developers expressed they do not mind the "ugly" solution

## `pinned-init`

## Wedson's RCU field projection

Gary: field projection makes RCU better to use

Gary: posted solution in the [RFC](https://github.com/rust-lang/rfcs/pull/3318#issuecomment-1264201012)

Benno: would this suffice?

unsafe trait RCUProjectable {}

impl<T> Mutex<T> {
    pub fn rcu_stuff(&self) -> RCUProjected<'_, T>
    where
        T: RCUProjectable
    { ... }
}

pub struct RCUProjected<'a, T> {...}

impl<T> RCUList<T> {
    fn head(self: RCUProjected<T>) {...}
}

Answer: no, we can still get `&mut` via `lock` and have `RCUProjected<'a, T'>` at the same time...

Gary: With field-projection crate you might be able to something like this:

#[rcu]
struct RcuList<T> {
    head: Rcu<Option<Box<Entry<T>>>>,
    tail: *mut Box<Entry<T>>,
}

impl<T> RcuMutex<T> {
    fn lock(&self) -> RcuMutexGuard<&'_, T>;
}

// With guard
let mut guard = mutex.lock();
// guard does not impl DerefMut
let _: &Rcu<Option<_>> = &guard.head; // okay
let _: &*mut Box<_> = &guard.tail; // okay
&mut guard.tail; // not okay
let _ : &mut *mut Box<_> = project(guard => tail); // this gives a `&mut`
// could be `guard->tail`
project(guard => head); // either not okay or &Rcu<_>

// Without guard
let _: &Rcu<_> = project(mutex => head); // this `&Rcu<>`
// could be `mutex->head`
project(mutex => tail) // not okay

Gary: will hack up a solution for next time

## `pin-project`

Benno: `UnsafeUnpin` has unsatisfiable safety requirements with `pinned-init`, if we vendor it, then we need to remove it.

## Bikeshed: `new_mutex!` vs `mutex_new!`

Gary: I hope we can write `Mutex::new()`!

Wedson: Investigate macro 2.0. `mutex::new!()`.

We can solve this via `pub use mutex_new as new;` inside the mutex module.

## Postponed
- async
- general planning: keep date topic to todo's only?