Messages in this thread | | | Date | Mon, 08 Sep 2008 13:11:59 -0700 | From | Mike Travis <> | Subject | Re: [PATCH 0/3] smp: reduce stack requirements for smp_call_function_mask |
| |
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
| |