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
| ||
|
Message-Id: <20160814.211318.898694274813674125.davem@davemloft.net> Date: Sun, 14 Aug 2016 21:13:18 -0700 (PDT) From: David Miller <davem@...emloft.net> To: fw@...len.de Cc: netdev@...r.kernel.org, tgraf@...g.ch Subject: Re: [PATCH net] rhashtable: avoid large lock-array allocations From: Florian Westphal <fw@...len.de> Date: Fri, 12 Aug 2016 04:13:43 +0200 > Sander reports following splat after netfilter nat bysrc table got > converted to rhashtable: > > swapper/0: page allocation failure: order:3, mode:0x2084020(GFP_ATOMIC|__GFP_COMP) > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc1 [..] > [<ffffffff811633ed>] warn_alloc_failed+0xdd/0x140 > [<ffffffff811638b1>] __alloc_pages_nodemask+0x3e1/0xcf0 > [<ffffffff811a72ed>] alloc_pages_current+0x8d/0x110 > [<ffffffff8117cb7f>] kmalloc_order+0x1f/0x70 > [<ffffffff811aec19>] __kmalloc+0x129/0x140 > [<ffffffff8146d561>] bucket_table_alloc+0xc1/0x1d0 > [<ffffffff8146da1d>] rhashtable_insert_rehash+0x5d/0xe0 > [<ffffffff819fcfff>] nf_nat_setup_info+0x2ef/0x400 > > The failure happens when allocating the spinlock array. > Even with GFP_KERNEL its unlikely for such a large allocation > to succeed. > > Thomas Graf pointed me at inet_ehash_locks_alloc(), so in addition > to adding NOWARN for atomic allocations this also makes the bucket-array > sizing more conservative. > > In commit 095dc8e0c3686 ("tcp: fix/cleanup inet_ehash_locks_alloc()"), > Eric Dumazet says: "Budget 2 cache lines per cpu worth of 'spinlocks'". > IOW, consider size needed by a single spinlock when determining > number of locks per cpu. > > Currently, rhashtable just allocates 128 locks per cpu which gives > factor of 4 more than what inet hashtable uses with same number of > cpus. > > For LOCKDEP, we now allocate a lot less locks than before (1 per cpu on > my test box) so we no longer need to pretend we only have two cpus. > > Some sizes (64 byte L1 cache, 4 byte per spinlock, numbers in bytes): > > cpus: 1 2 4 8 16 32 64 > old: 1k 1k 4k 8k 16k 16k 16k > new: 128 256 512 1k 2k 4k 8k > > With 72-byte spinlock (LOCKDEP): > cpus : 1 2 4 8 16 32 64 > old: 9k 18k 18k 18k 18k 18k 18k > new: 72 144 288 575 ~1k ~2.3k ~4k > > Reported-by: Sander Eikelenboom <linux@...elenboom.it> > Suggested-by: Thomas Graf <tgraf@...g.ch> > Signed-off-by: Florian Westphal <fw@...len.de> Applied, thanks Florian.
Powered by blists - more mailing lists