panic : problem in retrying the scsi command in case of CHECK_CON

[MEHTA,HIREN]

Hi All,

I believe that this is a bug in the scsi layer (scsi_io_completion() in
scsi_lib.c).

If you look at the routine scsi_io_completion(), if the device returned
check condition with bus reset and no data is transferred, then good_sectors
will
be 0.  scsi_io_completion tries to do retry by calling
scsi_queue_next_request().
But before that, it sets the request_buffer and buffer pointers to NULL. 
so, when the ll-driver gets the Scsi_Cmnd, this pointers are NULL which are
used to either access the buffer itself or the scatter-gather list and
if the low-level driver tries to access the scatter-gather list
it panics the system.

The following is the code that I am talking about :

	/*
	 * Zero these out.  They now point to freed memory, and it is
	 * dangerous to hang onto the pointers.
	 */
	SCpnt->buffer  = NULL;
	SCpnt->bufflen = 0;
	SCpnt->request_buffer = NULL;    ----> here it zeroes out the
request_buffer.
	SCpnt->request_bufflen = 0;

      ............

      	if ((SCpnt->sense_buffer[0] & 0x7f) == 0x70
		    && (SCpnt->sense_buffer[2] & 0xf) == UNIT_ATTENTION) {
			if (SCpnt->device->removable) {
				/* detected disc change.  set a bit and
quietly refuse
				 * further access.
				 */
				SCpnt->device->changed = 1;
				SCpnt = scsi_end_request(SCpnt, 0,
this_count);
				return;
			} else {
				/*
				 * Must have been a power glitch, or a
				 * bus reset.  Could not have been a
				 * media change, so we just retry the
				 * request and see what happens.  
				 */
				scsi_queue_next_request(q, SCpnt);  --> here
we try to do retry.
				return;
			}
		}

Has this been fixed  in later versions of the kernel ? 
any comment on the above code ?

Thanks and regards,
-hiren