On Wed, Feb 26, 2020 at 10:55 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote:
>
> Instead allocate hash tables with just the right size based on the
> actual number of elements (which is almost always known beforehand, we
> just need to defer the hashtab allocation to the right time). The only
> case when we don't know the size (with the current policy format) is the
> new filename transitions hashtable. Here I just left the existing value.
>
> After this patch, the time to load Fedora policy on x86_64 decreases
> from 790 ms to 167 ms. If the unconfined module is removed, it decreases
> from 750 ms to 122 ms. It is also likely that other operations are going
> to be faster, mainly string_to_context_struct() or mls_compute_sid(),
> but I didn't try to quantify that.
>
> The memory usage of all hash table arrays increases from ~58 KB to
> ~163 KB (with Fedora policy on x86_64).
>
> Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
> ---
> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
> index 32b3a8acf96f..7ca8c74efba3 100644
> --- a/security/selinux/ss/policydb.c
> +++ b/security/selinux/ss/policydb.c
> @@ -503,20 +482,12 @@ static int policydb_init(struct policydb *p)
> goto out;
> }
>
> - p->range_tr = hashtab_create(rangetr_hash, rangetr_cmp, 256);
> - if (!p->range_tr) {
> - rc = -ENOMEM;
> - goto out;
> - }
> -
> ebitmap_init(&p->filename_trans_ttypes);
> ebitmap_init(&p->policycaps);
> ebitmap_init(&p->permissive_map);
>
> return 0;
> out:
> - hashtab_destroy(p->filename_trans);
> - hashtab_destroy(p->range_tr);
> for (i = 0; i < SYM_NUM; i++) {
> hashtab_map(p->symtab[i].table, destroy_f[i], NULL);
> hashtab_destroy(p->symtab[i].table);
Sorry, just pointed out to me that this left the symtab destruction
code in the out path of policydb_init()
even though we are no longer creating them there. Harmless but should
be dropped.
