Messages in this thread | | | Date | Tue, 15 May 2018 11:37:20 +0800 | From | Herbert Xu <> | Subject | Re: [PATCH] lib/rhashtable: reorder some inititalization sequences |
| |
On Mon, May 14, 2018 at 10:52:13PM -0400, David Miller wrote: > From: Davidlohr Bueso <dave@stgolabs.net> > Date: Mon, 14 May 2018 08:13:32 -0700 > > > rhashtable_init() allocates memory at the very end of the > > call, once everything is setup; with the exception of the > > nelems parameter. However, unless the user is doing something > > bogus with params for which -EINVAL is returned, memory > > allocation is the only operation that can trigger the call > > to fail. > > > > Thus move bucket_table_alloc() up such that we fail back to > > the caller asap, instead of doing useless checks. This is > > safe as the the table allocation isn't using the halfly > > setup 'ht' structure and bucket_table_alloc() call chain only > > ends up using the ht->nulls_base member in INIT_RHT_NULLS_HEAD. > > > > Also move the locking initialization down to the end. > > > > Signed-off-by: Davidlohr Bueso <dbueso@suse.de> > > The user potentially "doing something bogus" is why the most > expensive part of the initialization (the memory allocation) > is done after everything else is validated. > > I think it's best to keep things as-is.
I agree.
Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
| |