On 04/24/15 at 08:57am, Herbert Xu wrote: > It seems that I lost track somewhere along the line. I meant > to add an explicit limit on the overall number of entries since > that was what users like netlink expected but never got around > to doing it. Instead it seems that we're currently relying on > the rht_grow_above_100 to protect us.
Can we please just take Johannes's fix as-is first? It fixes the bug at hand in an isolated manner without introducing any new knobs. Your patch includes his fix as-is without modification anyway. > So here is a patch that adds an explicit limit and fixes the > problem Johannes reported. > > ---8<--- > We currently have no limit on the number of elements in a hash table. > This is very bad especially considering that some rhashtable users > had such a limit before the conversion and relied on it for defence > against DoS attacks. Which users are you talking about? Both Netlink and TIPC still have an upper limit. nft sets are controlled by privileged users. > We already have a maximum hash table size limit but its enforcement > is only by luck and results in a nasty WARN_ON. As I stated earlier, this is no longer the case and thus this paragraph only confuses the commit message. > This patch adds a new paramater insecure_max_entries which becomes > the cap on the table. If unset it defaults to max_size. If it is > also zero it means that there is no cap on the number of elements > in the table. However, the table will grow whenever the utilisation > hits 100% and if that growth fails, you will get ENOMEM on insertion. Last time we discussed this it was said that the caller should enforce the limit like Netlink does. I'm fine with adding an upper max but I'd like to discuss that in the context of a full series which converts all existing enforcements and also contains a testing mechanism to verify this. Also, unless you can show me where this is currently a real bug, this is really net-next material. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
