netdev - Re: [PATCH v2 1/2] rhashtable: require max_shift if grow

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]

Message-Id: <20150224.131828.1632037288300527014.davem@davemloft.net>
Date:	Tue, 24 Feb 2015 13:18:28 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	johunt@...mai.com
Cc:	pablo@...filter.org, kaber@...sh.net, tgraf@...g.ch,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
	daniel@...earbox.net
Subject: Re: [PATCH v2 1/2] rhashtable: require max_shift if grow_decision
 defined

From: Josh Hunt <johunt@...mai.com>
Date: Tue, 24 Feb 2015 11:10:57 -0500

> If an rhashtable user defines a grow_decision fn they must also define a
> max_shift parameter.
> 
> Signed-off-by: Josh Hunt <johunt@...mai.com>

I've already said today that I think this whole indirection stuff
with grow and shrink decisions should simply go away.

Everyone defines it to the generic rhashtable routine, therefore
that should just be made private to lib/rhashtable.c, called
directly, and the methods completely removed.

Given that, this change makes no sense.

When a limit is not specified, we should unconditionally grow rather
than refuse to grow.  One should not be required to specify this at
all.  If you have no idea what limit might be reasonable, you specify
nothing at all and just let available memory be the limiting factor.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html