Re: [PATCH] lib/tests: kunit for associative array

[Jarkko Sakkinen <jarkko@kernel.org>]

On Wed, Oct 14, 2026 at 08:03:50PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 14, 2026 at 07:56:32PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 14, 2026 at 06:35:50PM +0200, Eric Biggers wrote:
> > > On Wed, Oct 14, 2026 at 07:01:38PM +0300, Jarkko Sakkinen wrote:
> > > > This is a kunit test for lib/assoc_array.c, which maintains a shadow model
> > > > across assoc_array operations, and checks its integrity after every
> > > > operation.
> > > > 
> > > > I wrote a draft version so that I could properly test 'assoc-array-fixes'
> > > > tag at Linus' tree, and spent today rewriting a new more polished version
> > > > with as good description as I could possibly could on how the seeded test
> > > > keys were cherry-picked. Along the way I also tweaked the numbers to be
> > > > a bit less messier set than in my original version.
> > > > 
> > > > The transcripts that follow were executed with this command-line:
> > > > 
> > > >     ./tools/testing/kunit/kunit.py run --raw_output assoc_array
> > > > 
> > > > With 'assoc-array-fixes' commits and its subsequent tag iterations all
> > > > eight tests pass, and without them all of them fail.
> > > > 
> > > > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > 
> > > Would this effort (and Linus's effort) be better spent on converting
> > > keyrings to use an rhashtable?
> > 
> > It did cross my mind when I reviewed and tested those fixes but you
> > are asking something that I would need at least a few hours to have
> > any opinion.
> > 
> > We do bugs and QA to the end-of-life-cycle. We neither can predict
> > exact time how such major overhaul would take, if we even want to
> > do it. I don't know.
> > 
> > My brain is on this and I'm really bad at multitasking :-)
> 
> If migration was done probably two-phase approach is what should
> sought after. I.e. keep the API and change the internals.
> 
> After that it is time for re-consideration because from that point
> there are multiple (API) paths forward.

rhashtable is the best pick I think. xarray not so much given the
data topology.

Br, Jarkko