This patch adds code that handles GFP_ATOMIC kmalloc failure on
insertion. As we cannot use vmalloc, we solve it by making our
hash table nested. That is, we allocate single pages at each level
and reach our desired table size by nesting them.
When a nested table is created, only a single page i
On Tue, Feb 07, 2017 at 07:02:16PM +0100, Florian Westphal wrote:
>
> I can't really say anything here because *I* don't expect
> it to succeed.
Think about incoming TCP connections, you can't rate-limit that
without defeating yourself.
> Even with this proposed patch things will eventually fail
Herbert Xu wrote:
> On Tue, Feb 07, 2017 at 02:17:28PM +0100, Florian Westphal wrote:
> >
> > Ok, but why?
>
> Because people expect the hash table insertion to succeed, even
> on softirq paths where you cannot vmalloc.
I can't really say anything here because *I* don't expect
it to succeed.
>
On Tue, Feb 07, 2017 at 02:17:28PM +0100, Florian Westphal wrote:
>
> Ok, but why?
Because people expect the hash table insertion to succeed, even
on softirq paths where you cannot vmalloc.
> It seems to add a whole lot of complexity...
>
> What users can't handle the insert failure case until r
Herbert Xu wrote:
> This patch adds code that handles GFP_ATOMIC kmalloc failure on
> insertion. As we cannot use vmalloc, we solve it by making our
> hash table nested. That is, we allocate single pages at each level
> and reach our desired table size by nesting them.
>
> When a nested table i
This patch adds code that handles GFP_ATOMIC kmalloc failure on
insertion. As we cannot use vmalloc, we solve it by making our
hash table nested. That is, we allocate single pages at each level
and reach our desired table size by nesting them.
When a nested table is created, only a single page i
