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. -- 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