On 02/10/2015 11:44 AM, Patrick McHardy wrote:
Am 10. Februar 2015 18:22:41 MEZ, schrieb Thomas Graf <tgraf@xxxxxxx>:
On 02/10/15 at 06:06pm, Daniel Borkmann wrote:
Hm, given that min_shift/max_shift are parameters that directly
concern internals of rhashtable i.e. are tightly coupled to expand
and shrink functionality, I'd say that depending on the use case,
a maxelem limit should rather be handled outside of it, if it's
truly an issue/concern.
Agreed, Netlink already uses the atomic counter of rhashtable to
enforce upper limit of table entries:
err = -ENOMEM;
if (BITS_PER_LONG > 32 &&
unlikely(atomic_read(&table->hash.nelems) >= UINT_MAX))
goto err;
I would tend to agree with Pablo, now we're handling half (shift) internally and half (max) externally, using internal values.
OK. Thanks for all the feedback. I will send a v2 once the other 2
patches get reviewed.
Thanks
Josh
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
