Re: [PATCH 0/3] smp: reduce stack requirements for smp_call_function_mask

[Mike Travis <travis@sgi.com>]

David Miller wrote:
> From: Nick Piggin <nickpiggin@yahoo.com.au>
> Date: Mon, 8 Sep 2008 20:30:41 +1000
> 
>> Is that being tried? Setting it to 8192 or even higher during QA seems
>> like a good idea to me.
> 
> This is a great idea, especially since it will make it even more
> painfully obvious that essentially any function local cpumask_t
> variable is a bug.

Yes, that's what I have done in the past ... but putting it into the QA
testing would really trigger those stack overflow problems... ;-)

> 
> Really, it seems sensible to do something like:
> 
> 1) Make cpumask_t a pointer.
> 
> 2) Add cpumask_data_t which is what cpumask_t is now.  This gets
>    used when for the actual storage, and will only get applied to
>    datastructures that are dynamically allocated.  For example, for
>    the cpu_vm_mask in mm_struct.
> 
> 3) Type make and fix build failures until they are all gone.

I was wondering if we'd need to be able to default a cpumask_t pointer
argument to be a const and then use a different method for those cases
where it shouldn't be?  This would strengthen the compiler type checking
of functions calls.

For example:

	proto(cpumask_t mask)

would imply that *mask is a const, whereas

	proto(cpumask_var mask)

would indicate it to be non-const?

But then we couldn't use "cpumask_t" as a local declarator... So perhaps
we need something completely different for declaring cpumask arguments?

(I'm trying to figure out how to structure this with the least amount of
source editing.)

Thanks!
Mike