# Meeting 2023-08-30
<!-- Leave your topic starting with ### in the relevant sections below -->

## Critical
<!-- bugs, soundness issues, urgent patches/reviews etc. -->

## Status Reports

### LPC Rust MC

Miguel: Mostly decided. 25 minutes for each talk.

Miguel: limited sponsored/reserved registration slots

Gary: Trying to register as virtual speaker and code is mandatory

Miguel: It might mean something else? It's confusing. I think it's fine to register as the wrong type and they can change on their end.

Boqun: It's there a list of topic MC?

Gary: https://lpc.events/event/17/sessions/170/, click "contribution list"

Miguel: 4 use cases, 3 tooling, sounds like a good mix

<!-- You want to report on something you are working on/request reviews.
Or you want to know the status of something someone else is doing -->

## Discussion Questions
<!-- Anything that requires lengthy discussion/more general questions also fit here -->

### Extra files generated by Rust compiler

Miguel: Rust compiler sometimes generates extra file. Should the `.long-type.txt` file be placed in the .gitignore?

Alice: Where's this being placed?

Gary: Output directory.

Miguel: I think it should be in `.gitignore` like `.i` files

Gary: I am a bit worried that people see it in `.gitignore` and think they're often generated, but in reality they're generated in rare error cases for diagnostics.

### Hyper-V Util Driver

Boqun: Microsoft is working on Hyper-V util driver in Rust, not yet ready for upstream

Gary: Is this using the C code for VM packet/bus?

Boqun: Yes, currently a wrapper around the C interface. It's a simple ring buffer so we might move to something more Rusty.

### Webpage Ideas

Miguel: It'll be a nice page to show use cases that companies are interested in, without committing.

Miguel: There're things that will never be upstream (e.g. used in a university course), I want to gather it somewhere.

### Klint w/ Binder

Gary:

pub struct X;

impl Drop for X {
    #[klint::preempt_count(expect = 0)]
    fn drop(&mut self) {}
}

// klint don't like
#[klint::preempt_count(expect = 0..)]
pub fn foo(x: Option<X>) -> Option<X> {
    if let Some(x) = x {
        return Some(x);
    }
    None
}

// MIR of foo looks like this:
pub fn foo(x: Option<X>) -> Option<X> {
    if let Some(x) = x {
        return Some(x);
    }
    // This is a significant drop!!!
    drop(x);
    None
}

// klint likes
#[klint::preempt_count(expect = 0..)]
pub fn bar(x: Option<X>) -> Option<X> {
    match x {
        Some(x) => return Some(x),
        None => (),
    }
    None
}

Gary: another case

let mut state = something.lock()
loop {
    if condition() {
        drop(state);
        some_thing();
        break;
    }
}

causes drop flag creation.

Gary: Currently doing data-dependent analysis, but will see if it explodes. The issue is NP-hard.

Gary: A few cases where a `Arc` is dropped inside atomic context. E.g. `push_back` of `List` dropped an `Arc` inside atomic context.

Alice: This might actually be an issue if race happens and the last copy of `Arc` is actually.

Gary: For linked list it's taking `&mut` so it's fine?

Alice: It could be in another list.

Alice: I think for binder it's currently okay?

Gary: I think `Node` and `Process` dropping requires sleepable context due to `Arc`.

Gary: If Lina's lockdep Arc check is implemented, would lockdep also complain about dropping a non-last Arc.

Boqun: That's something unavoidable for `Arc`.

Gary: If your code temporarily increase the ref count of `Arc` and decrease it in the same function, you know the ref count won't drop to zero, but klint or lockdep.

Boqun:

struct WithRcu<T> {
    rcu_head: rcu_head, // <- linked list.
    data: T,
}

## Miscellaneous
<!-- stuff that does not fit into other categories -->