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: Tue, 1 Sep 2015 15:56:18 +0200 From: Phil Sutter <phil@....cc> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: tgraf@...g.ch, davem@...emloft.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, fengguang.wu@...el.com, wfg@...ux.intel.com, lkp@...org Subject: Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads On Tue, Sep 01, 2015 at 09:50:19PM +0800, Herbert Xu wrote: > On Tue, Sep 01, 2015 at 03:43:11PM +0200, Phil Sutter wrote: > > > > Hmm. Since memory allocation is first tried with GFP_ATOMIC set and upon > > failure retried in background, this seems like a situation which might > > happen during normal use. If that already indicates a severe problem, > > why retry in background at all? > > It should be tried in the background first at 70% and only when > that fails would we hit the 100% case and then we will try it > with GFP_ATOMIC. If that fails then the insertion will fail. Ah, good to know. Thanks for clarifying this! Looking at rhashtable_test.c, I see the initial table size is 8 entries. 70% of that is 5.6 entries, so background expansion is started after the 6th entry has been added, right? Given there are 10 threads running which try to insert 50k entries at the same time, I don't think it's unlikely that three more entries are inserted before the background expansion completes. Cheers, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists