netdev - Re: [PATCH net-next 6/7] net: Generic resolver backend

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]

Date:   Tue, 20 Sep 2016 17:40:43 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Tom Herbert <tom@...bertland.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, tgraf@...g.ch,
        roopa@...ulusnetworks.com, kernel-team@...com
Subject: Re: [PATCH net-next 6/7] net: Generic resolver backend

Tom Herbert <tom@...bertland.com> wrote:
>
> +       nrslv->params.head_offset = offsetof(struct net_rslv_ent, node);
> +       nrslv->params.key_offset = offsetof(struct net_rslv_ent, object);
> +       nrslv->params.key_len = key_len;
> +       nrslv->params.max_size = max_size;
> +       nrslv->params.min_size = 256;
> +       nrslv->params.automatic_shrinking = true;
> +       nrslv->params.obj_cmpfn = cmp_fn ? net_rslv_cmp : NULL;

This completely defeats the rhashtable inlining since that relies
on the parameter being constant.

Looking at your next patch you have exactly one user for this.  So
who is going to be the next user and do we really need all these
fields to be variable?

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt