Re: [PATCH 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

Ermm, actually this looks totally bogus..
CpqTsGetSFQEntry() ...

    if( total_bytes <= 2048 )
    {
      memcpy( ulDestPtr,
              &fcChip->SFQ->QEntry[consumerIndex],
              64 );  // each SFQ entry is 64 bytes
      ulDestPtr += 16;   // advance pointer to next 64 byte block
    }

we're trashing the last 48 bytes of every copy we make.
Does this driver even work ?

		Dave

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux