On Fri, 27 Feb 2026 16:28:51 -0800
Deborah Brouwer <[email protected]> wrote:
> > >
> > >>
> > >> access vs access_mut() does not matter here: since the owner is &mut self
> > >> anyways we know we have exclusive access to the LockedSeat throughout
> > >> the whole
> > >> function.
> > >
> > > I agree, but LockedBy is picky, and last I tried I couldn't make it
> > > work without the annoying update+return-copy-of-seat dance you see
> > > here. Maybe I missed something obvious and it does indeed work with
> > > your suggested changes, dunno.
> >
> > Rewriting things so they pass the borrow checker is common in Rust.
> > Sometimes
> > it can be done rather easily; other times the design is just broken and
> > needs
> > to be reworked. Luckily this one fell in the first category.
> >
> > This benefits from the fact that no one can race us between reading this
> > tuple
> >
> > (slot_idx, seqno, is_active)
> >
> > ..and using it. That’s because we’re taking &mut self as a proxy in
> > LockedBy, so
> > we’re sure we have exclusive access in this scope.
Yep, I know that, but I seem to remember it wasn't working when I was doing
match locked_seat.access(self) {
Seat::Active(seat_info) | Seat::Idle(seat_info) => {
// With lazy eviction, if seqno matches, the hardware state is
still
// valid for both Active and Idle slots, so just update our
records
self.record_active_slot(seat_info.slot as usize, locked_seat,
slot_data)
}
_ => self.allocate_slot(locked_seat, slot_data),
}
in ::activate(), which is why I made check_seat() return a Seat and
did the match against this returned seat. Oh well, I must have
misunderstood the problem reported by the compiler.
> >
> > If you don’t have any complaints about the code I sent (i.e.: convoluted,
> > wrong
> > logic, etc), I suggest switching to it.
>
> I’ve tested the short check_seat() function and can confirm that it correctly
> compares Seat and Slot seqno as well as emits the kernel warning when we have
> a
> mismatch on an active Seat. So I’ll the simplified check_seat() function in v2
> unless there are any more issues to address.
If things still compile/work as expected, no objection on my end.
