On Mon, Mar 2, 2020 at 2:11 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> 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.
Ondrej, can you submit a cleanup patch for this?
--
paul moore
www.paul-moore.com
