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, 05 Jun 2012 22:41:46 +0200 From: Sasha Levin <levinsasha928@...il.com> To: Seth Jennings <sjenning@...ux.vnet.ibm.com> Cc: gregkh@...uxfoundation.org, dan.magenheimer@...cle.com, konrad.wilk@...cle.com, devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] zcache: don't limit number of pools per client On Tue, 2012-06-05 at 15:19 -0500, Seth Jennings wrote: > > + pool = idr_find(&cli->tmem_pools, poolid); > > + if (pool != NULL) > > + atomic_inc(&pool->refcount); > > > This is called on the main path, so it needs to be fast. There is so much > contention elsewhere in the stack I don't think it'll be an issue. It looks > like idr_find() is fast, even though it contains a loop. Just needs to be > considered. Agreed. idr actually uses something which looks like a hash table, so it should be fast enough for this case. > > +retry: > > + r = idr_pre_get(&cli->tmem_pools, GFP_ATOMIC); > > > + if (r != 1) { > > + kfree(pool); > > + pr_info("zcache: pool creation failed: out of memory\n"); > > + goto out; > > + } > > + r = idr_get_new(&cli->tmem_pools, pool, &poolid); > > + switch (r) { > > + case 0: > > + break; > > + case -EAGAIN: > > + goto retry; > > + default: > > + pr_info("zcache: pool creation failed: error %d\n", r); > > kfree(pool); > > - poolid = -1; > > goto out; > > } > > + > > > how about: > ===== > do { > r = idr_pre_get(&cli->tmem_pools, GFP_ATOMIC); > if (r != 1) { > kfree(pool); > pr_info("zcache: pool creation failed: out of memory\n"); > goto out; > } > r = idr_get_new(&cli->tmem_pools, pool, &poolid); > } > while (r == -EAGAIN) > > if (r) { > pr_info("zcache: pool creation failed: error %d\n", r); > kfree(pool); > goto out; > } > ===== > so we can lose the label/goto. > > Also, do we want GFP_ATOMIC? Why not GFP_KERNEL? I wasn't sure about the context this code runs at, and assumed it's atomic one due to the kmalloc allocating with GFP_ATOMIC just couple of lines above the idr_pre_get. If that's wrong, we can switch that kmalloc as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists