Skip to contentSkip to conversation

SCSI Tape driver problem

DISCUSSION vijay srinath 2 participants 2 messages Jul 31, 2001

lore
Share & tools
lore
#0 lore raw

hello all,

I noticed a bug in the scsi tape class driver in kernel 2.2.16/2.4.x.
This is the test that i ran.
1. I have two scsi-fc tape devices
2. I insert the hba driver, so that both the tape devices are enabled and map to st0 and st1
3. I remove the device that maps to st0 using
echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi
4. Now, if i try to do an open("/dev/st1",..), the process hangs as the open call never returns.

The problem seems to be in the callback function st_sleep_done() where the following comparison is being made
if ((st_nbr = TAPE_NR(SCpnt->request.rq_dev)) < st_template.nr_dev)
{
...
}

This comparision fails for the above test since nr_dev will be 1 and TAPE_NR() will also be 1 for /dev/st1. Hence the semaphore SCpnt->request.sem never gets released and open waits forever.

Can somebody please let me know why this comparison is needed ?

regards
vijay

Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/

#1 lore raw
Quoted 16 lines · vijay srinath

hello all,

I noticed a bug in the scsi tape class driver in kernel 2.2.16/2.4.x.
This is the test that i ran.
1. I have two scsi-fc tape devices
2. I insert the hba driver, so that both the tape devices are enabled and map to st0 and st1
3. I remove the device that maps to st0 using
echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi
4. Now, if i try to do an open("/dev/st1",..), the process hangs as the open call never returns.

The problem seems to be in the callback function st_sleep_done() where the following comparison is being made
if ((st_nbr = TAPE_NR(SCpnt->request.rq_dev)) < st_template.nr_dev)
{
...
}

Quoted 7 lines

This comparision fails for the above test since nr_dev will be 1 and TAPE_NR() will also be 1 for /dev/st1. Hence the semaphore SCpnt->request.sem never gets released and open waits forever.

Can somebody please let me know why this comparison is needed ?

The test was inserted a long time ago to be an additional safeguard against problems in the code. In normal operation the interrupt function should never be called with an illegal argument. It seems that the world around the test has evolved so that the test is not working properly any more.

You can just remove the test. I will prepare a patch to fix this bug and send the patch to Linus.

Kai