lkml.org 
[lkml]   [2005]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel
Date
Dave Jones wrote:
>On Thu, Aug 04, 2005 at 05:56:14PM +0200, Rolf Eike Beer wrote:
> > Am Donnerstag, 4. August 2005 17:40 schrieb Dave Jones:
> > >On Thu, Aug 04, 2005 at 11:38:30AM +0200, Rolf Eike Beer wrote:
> > > > >+ ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
> > > >
> > > > The size bug was already found by Dave Jones. This never should be
> > > > written this way (not your fault). The array should have been
> > > > [2048/sizeof(ULONG)].
> > >
> > >wasteful. We only ever use 2048 bytes of this array, so doubling
> > >its size on 64bit is pointless, unless you make changes later on
> > >in the driver. (Which I think don't make sense, as we just copy
> > >32 64byte chunks).
> >
> > No, this is how it should have been before. This way it would have been
> > clear where the magic 4 came from.
>
>It's pointless to fix this, without fixing also CpqTsGetSFQEntry()
>...

At least half of the file should be rewritten.

> > >we're trashing the last 48 bytes of every copy we make.
> > >Does this driver even work ?
> >
> > No, ulDestPtr ist ULONG* so we increase it by sizeof(ULONG)*16 which is
> > 64.
>
>Duh, yes. That is broken on 64-bit however, where it will advance 128 bytes
>instead of 64 bytes.

ULONG is defined to __u32 in some of the cpq* headers.

Eike
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-08-04 19:20    [W:0.081 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site