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
| ||
|
Date: Fri, 26 Aug 2016 10:27:03 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Cong Wang <xiyou.wangcong@...il.com> Cc: Eric Dumazet <edumazet@...gle.com>, CAI Qian <caiqian@...hat.com>, Thomas Graf <tgraf@...g.ch>, Herbert Xu <herbert@...dor.apana.org.au>, Network Development <netdev@...r.kernel.org> Subject: Re: possible memory leak in ipc On Fri, Aug 26, 2016 at 10:04 AM, Cong Wang <xiyou.wangcong@...il.com> wrote: > > It was correct until... > > commit 4cf0b354d92ee2c642532ee39e330f8f580fd985 > Author: Florian Westphal <fw@...len.de> > Date: Fri Aug 12 12:03:52 2016 +0200 > > rhashtable: avoid large lock-array allocations > > > which is: > > @@ -83,6 +83,9 @@ static int alloc_bucket_locks(struct rhashtable *ht, > struct bucket_table *tbl, > tbl->locks = vmalloc(size * sizeof(spinlock_t)); > else > #endif > + if (gfp != GFP_KERNEL) > + gfp |= __GFP_NOWARN | __GFP_NORETRY; > + > tbl->locks = kmalloc_array(size, sizeof(spinlock_t), > gfp); Heh. Yeah, this is a classic case of something we should *not* do. And I'm not speaking out against that commit 4cf0b354d92e itself: that isn't the problem. The problem is that #ifdef with the rather subtle dangling 'else'. Oops. I even *looked* at that function yesterday, and didn't realize the (in hindsight) obvious bug because the code had that odd pattern. I see that Eric sent a patch and fixed the bug, and in the process got rid of that dangling else thing. Thanks guys, Linus
Powered by blists - more mailing lists