Messages in this thread | | | Date | Sat, 06 Jun 2009 02:36:57 -0700 | From | Yinghai Lu <> | Subject | Re: [PATCH] cpumask: alloc blank cpumask left over |
| |
Avi Kivity wrote: > Rusty Russell wrote: >> On Fri, 5 Jun 2009 03:26:57 pm Yinghai Lu wrote: >> >>> Rusty Russell wrote: >>> >>>> On Fri, 5 Jun 2009 06:31:31 am Yinghai Lu wrote: >>>> >>>>> avoid suprise when MAXSMP is enabled >>>>> >>>>> Signed-off-by: Yinghai Lu <yinghai.lu@kernel.org> >>>>> >>>> I understand the temptation, but two questions arise: >>>> 1) Shouldn't we actually audit to see if any of these are currently >>>> problems, >>>> >>> those are defined as static cpumask_var_t, and if MAXSMP is not used, >>> they >>> are cleared already >>> >> >> OK, here's what I've got in my tree. Ingo, I think this should go in the >> current -rc to avoid nasty bugs. >> >> BTW, the original alloc_cpumask_var did zero; that was dropped after >> arguments >> over efficiency and fitting with other interfaces, but I clearly had >> the old >> semantics in my head for a while. >> >> > > Using __GFP_ZERO is equivalent to using memset() instead of > cpumask_clear(). It's better to call cpumask_clear() or provide an API > to alloc+clear. > > Further, what about the non-MAXSMP case: > > > static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags) > { > return true; > } > > > We explicity clear on MAXSMP and rely on static initialization for the > non-MAXSMP, laying a neat trap for anyone who makes the variable > non-static. Let's be less subtle that that.
or have zalloc_cpumask_var() ?
YH
| |