[lkml]   [2008]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] smp: reduce stack requirements for smp_call_function_mask
David Miller wrote:
> From: Nick Piggin <>
> 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.)


 \ /
  Last update: 2008-09-08 22:15    [W:0.034 / U:3.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site