linux-kernel - Re: [PATCH 0/3] smp: reduce stack requirements for smp_call_function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 08 Sep 2008 13:11:59 -0700
From:	Mike Travis <travis@....com>
To:	David Miller <davem@...emloft.net>
CC:	nickpiggin@...oo.com.au, mingo@...e.hu, akpm@...ux-foundation.org,
	steiner@....com, jes@....com, tglx@...utronix.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] smp: reduce stack requirements for smp_call_function_mask

David Miller wrote:
> From: Nick Piggin <nickpiggin@...oo.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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/