On Tue, Jun 17, 2025 at 11:24 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Fri, Jun 13, 2025 at 04:58:27PM +0200, Pratyush Yadav wrote: > > On Sat, Jun 07 2025, Pasha Tatashin wrote: > > [...] > > >> > > >> This weirdness happens because luo_prepare() and luo_cancel() control > > >> the KHO state machine, but then also get controlled by it via the > > >> notifier callbacks. So the relationship between then is not clear. > > >> __luo_prepare() at least needs access to struct kho_serialization, so it > > >> needs to come from the callback. So I don't have a clear way to clean > > >> this all up off the top of my head. > > > > > > On production machine, without KHO_DEBUGFS, only LUO can control KHO > > > state, but if debugfs is enabled, KHO can be finalized manually, and > > > in this case LUO transitions to prepared state. In both cases, the > > > path is identical. The KHO debugfs path is only for > > > developers/debugging purposes. > > > > What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then > > KHO calls into LUO from the notifier, which makes the control flow > > somewhat convoluted. If LUO is supposed to be the only thing that > > interacts directly with KHO, maybe we should get rid of the notifier and > > only let LUO drive things. > > Yes, we should. I think we should consider the KHO notifiers and self > orchestration as obsoleted by LUO. That's why it was in debugfs > because we were not ready to commit to it. We could do that, however, there is one example KHO user `reserve_mem`, that is also not liveupdate related. So, it should either be removed or modified to be handled by LUO. Mike, what do you think? Pasha
