netdev - Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec

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: <20200516.163927.1112911965183377217.davem@davemloft.net>
Date:   Sat, 16 May 2020 16:39:27 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     shakeelb@...gle.com
Cc:     edumazet@...gle.com, willemb@...gle.com, kuba@...nel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net/packet: simply allocations in alloc_one_pg_vec_page

From: Shakeel Butt <shakeelb@...gle.com>
Date: Sat, 16 May 2020 15:35:46 -0700

> So, my argument is if non-zero order vzalloc has failed (allocations
> internal to vzalloc, including virtual mapping allocation and page
> table allocations, are order 0 and use GFP_KERNEL i.e. triggering
> reclaim and oom-killer) then the next non-zero order page allocation
> has very low chance of succeeding.

Also not true.

Page table allocation strategies and limits vary by architecture, they
may even need virtual mappings themselves.  So they can fail in situations
where a non-zero GFP_KERNEL page allocator allocation would succeed.