Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Thu, 08 Jun 2023 22:03:30 +0300
Message-Id: <CT7I3FSMNR0V.8DOJ8GZ6LPDK@suppilovahvero>
Cc:     <keyrings@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] keys: Fix linking a duplicate key to a keyring's
 assoc_array
From:   "Jarkko Sakkinen" <jarkko@kernel.org>
To:     "David Howells" <dhowells@redhat.com>,
        "Petr Pavlu" <petr.pavlu@suse.com>
References: <20230323130412.32097-1-petr.pavlu@suse.com>
 <2413881.1686233574@warthog.procyon.org.uk>
In-Reply-To: <2413881.1686233574@warthog.procyon.org.uk>
Precedence: bulk

On Thu Jun 8, 2023 at 5:12 PM EEST, David Howells wrote:
> Apologies for missing this patch.
>
> Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> > * Back on the first task, function construct_alloc_key() first runs
> >   __key_link_begin() to determine an assoc_array_edit operation to
> >   insert a new key. Index keys in the array are compared exactly as-is,
> >   using keyring_compare_object(). The operation finds that "abcdef" is
> >   not yet present in the destination keyring.
>
> Good catch, but I think it's probably the wrong solution.
>
> keyring_compare_object() needs to use the ->cmp() function from the key t=
ype.
>
> It's not just request_key() that might have a problem, but also key_link(=
).
>
> There are also asymmetric keys which match against multiple criteria - th=
ough
> I'm fine with just matching the main description there (the important bit
> being to maintain the integrity of the tree inside assoc_array).
>
> I wonder, should I scrap the assoc_array approach and go to each keyring =
being
> a linked-list?  It's slower, but a lot easier to manage - and more forgiv=
ing
> of problems.
>
> 	struct key_ptr {
> 		struct list_head	link;
> 		struct key		*key;
> 		unsigned long		key_hash;
> 	};
>
> I'm also wondering if I should remove the key type from the matching crit=
eria
> - i.e. there can only be one key with any particular description in a rin=
g at
> once, regardless of type.  Unfortunately, this is may be a UAPI breaker
> somewhere.
>
> Any thoughts?

If the amount of items stays at most in hundreds (or actually even like
few thousand items), there's very little gain of having the complexity
of associative array. In most cases it probably shoots back in many
ways.

I've been thinking this for a long time but have thought that since it
has been there, there must be good reasons to have it.

So yeah, definitely +1 for scraping assoc array.

BR, Jarkko