On Tue, Jan 03, 2006 at 02:51:46PM +0100, Rolf Eike Beer wrote: > Marcelo Tosatti wrote: > >On Mon, Jan 02, 2006 at 01:05:37PM +0100, Rolf Eike Beer wrote: > >> There are 2 function that do a lookup to the queue and buffer the result. > >> They only care about the first few bytes (to be exactly: 38*sizeof(u32)), > >> but they always pass a buffer of 2kB, which is located on the stack. > >> > >> This patch reduces this buffer to the really needed size and changes it's > >> type to the correct target type. The rest of the queue is still looked up > >> but the result is ignored (as it would anyway). > >> > >> There are also some small cleanups for the other arguments of > >> CpqTsGetSFQEntry(), which is the lookup function. > > >Is there an evidence that the gratuitous stack usage is causing problems > > with an 8kB stack? > > > >In other ways, this looks more like an optimization than a serious bugfix? > > I have no reports of this, but this proves nothing. But why waste one quarter > of the stack for nothing? My point is that v2.4 is into deep maintenance mode, which means that only critical bug fixes get merged into the tree. I'm not against the patch per se. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
