tree 9012c689500d33f576c99f00235f44901c86a6cc
parent 5b9851b5511833a96fea2196971b5709ef019136
author Jesper Juhl <jesper.juhl@gmail.com> 1147559978 +0200
committer James Bottomley <jejb@mulgrave.il.steeleye.com> 1148135003 -0500

[SCSI] fix (unlikely) memory leak in DAC960 driver

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: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>