1. 02 Jul, 2006 1 commit
  2. 01 Jul, 2006 1 commit
  3. 30 Jun, 2006 1 commit
  4. 29 Jun, 2006 1 commit
  5. 28 Jun, 2006 1 commit
  6. 27 Jun, 2006 1 commit
  7. 26 Jun, 2006 9 commits
  8. 25 Jun, 2006 14 commits
  9. 23 Jun, 2006 2 commits
  10. 21 Jun, 2006 4 commits
  11. 17 Jun, 2006 1 commit
    • Herbert Xu's avatar
      [NET]: Clean up skb_linearize · 364c6bad
      Herbert Xu authored
      The linearisation operation doesn't need to be super-optimised.  So we can
      replace __skb_linearize with __pskb_pull_tail which does the same thing but
      is more general.
      
      Also, most users of skb_linearize end up testing whether the skb is linear
      or not so it helps to make skb_linearize do just that.
      
      Some callers of skb_linearize also use it to copy cloned data, so it's
      useful to have a new function skb_linearize_cow to copy the data if it's
      either non-linear or cloned.
      
      Last but not least, I've removed the gfp argument since nobody uses it
      anymore.  If it's ever needed we can easily add it back.
      
      Misc bugs fixed by this patch:
      
      * via-velocity error handling (also, no SG => no frags)
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      364c6bad
  12. 06 Jun, 2006 1 commit
  13. 20 May, 2006 1 commit
    • Jesper Juhl's avatar
      [SCSI] fix (unlikely) memory leak in DAC960 driver · 07fb75a5
      Jesper Juhl authored
      The Coverity checker found a memory leak (bug nr. 1245) in
       drivers/block/DAC960.c::DAC960_V2_ProcessCompletedCommand()
      
      The leak is pretty unlikely since it requires that the first of two
      successive kmalloc() calls fail while the second one succeeds. But it can
      still happen even if it's unlikely.
      
      If the first call that allocates 'PhysicalDeviceInfo' fails but the one
      that allocates 'InquiryUnitSerialNumber' succeeds, then we will leak the
      memory allocated to 'InquiryUnitSerialNumber' when the variable goes out
      of scope.
      
      A simple fix for this is to change the existing code that frees
      'PhysicalDeviceInfo' if that one was allocated but
      'InquiryUnitSerialNumber' was not, into a check for either pointer
      being NULL and if so just free both. This is safe since kfree() can
      deal with being passed a NULL pointer and it avoids the leak.
      
      While I was there I also removed the casts of the kmalloc() return
      value since it's pointless.
      I also updated the driver version since this patch changes the workings of
      the code (however slightly).
      
      This issue could probably be fixed a lot more elegantly, but the code
      is a big mess IMHO and I just took the least intrusive route to a fix
      that I could find instead of starting on a cleanup as well (that can
      come later).
      
      Please consider for inclusion.
      Signed-off-by: default avatarJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      07fb75a5
  14. 18 May, 2006 1 commit
  15. 09 May, 2006 1 commit
    • Pete Zaitcev's avatar
      [PATCH] USB: ub oops in block_uevent · 77ef6c4d
      Pete Zaitcev authored
      In kernel 2.6.16, if a mounted storage device is removed, an oops happens
      because ub supplies an interface device (and kobject) to the block layer,
      but neglects to pin it. And apparently, the block layer expects its users
      to pin device structures.
      
      The code in ub was broken this way for years. But the bug was exposed only
      by 2.6.16 when it started to call block_uevent on close, which traverses
      device structures (kobjects actually).
      Signed-off-by: default avatarPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      77ef6c4d