linux-kernel - Re: [RFC v2 05/16] luo: luo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250617152357.GB1376515@ziepe.ca>
Date: Tue, 17 Jun 2025 12:23:57 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Pasha Tatashin <pasha.tatashin@...een.com>, jasonmiu@...gle.com,
	graf@...zon.com, changyuanl@...gle.com, rppt@...nel.org,
	dmatlack@...gle.com, rientjes@...gle.com, corbet@....net,
	rdunlap@...radead.org, ilpo.jarvinen@...ux.intel.com,
	kanie@...ux.alibaba.com, ojeda@...nel.org, aliceryhl@...gle.com,
	masahiroy@...nel.org, akpm@...ux-foundation.org, tj@...nel.org,
	yoann.congal@...le.fr, mmaurer@...gle.com, roman.gushchin@...ux.dev,
	chenridong@...wei.com, axboe@...nel.dk, mark.rutland@....com,
	jannh@...gle.com, vincent.guittot@...aro.org, hannes@...xchg.org,
	dan.j.williams@...el.com, david@...hat.com,
	joel.granados@...nel.org, rostedt@...dmis.org,
	anna.schumaker@...cle.com, song@...nel.org, zhangguopeng@...inos.cn,
	linux@...ssschuh.net, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-mm@...ck.org,
	gregkh@...uxfoundation.org, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
	hpa@...or.com, rafael@...nel.org, dakr@...nel.org,
	bartosz.golaszewski@...aro.org, cw00.choi@...sung.com,
	myungjoo.ham@...sung.com, yesanishhere@...il.com,
	Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
	aleksander.lobakin@...el.com, ira.weiny@...el.com,
	andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de,
	bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
	stuart.w.hayes@...il.com
Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO

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.

Jason