[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.0902251542010.15476@vixen.sonytel.be>
Date: Wed, 25 Feb 2009 15:44:02 +0100 (CET)
From: Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
To: Frank Seidel <fseidel@...e.de>
cc: Herbert Xu <herbert@...dor.apana.org.au>,
linux kernel <linux-kernel@...r.kernel.org>,
linux-crypto@...r.kernel.org, Frank Seidel <frank@...eidel.de>,
akpm@...ux-foundation.org, "David S. Miller" <davem@...emloft.net>,
nhorman@...driver.com, lho@...c.com, kaber@...sh.net,
darrenrjenkins@...il.com, Greg KH <gregkh@...e.de>
Subject: Re: [PATCH][trivial] crypto: tcrypt - reduce stack size
On Wed, 25 Feb 2009, Frank Seidel wrote:
> Geert Uytterhoeven wrote:
> > Probably people should be reminded tcrypt can only be a module, not built-in,
> > so it won't waste precious unswappable kernel memory if it's static.
>
> Thats right, but it also doesn't hurt to simply use kmalloc, does it? :-)
Wel...
Using kmalloc() increases code size, makes the code more complex, and increases
the risk of introducing a memory leak now or later.
> I just stumbled over tcrypt on the make checkstack output and as also
> the kerneljanitors todo advises to reduce this footprint where possible
> i just wanted to help out here.
Reducing stack usage is fine. However, for a loadable test module without
concurrency issues it's far easier to do that by just making the data static.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@...ycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
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/
Powered by blists - more mailing lists