Bug 118412 - [untested PATCH] SCSI host numbering messed up by reloading driver
[untested PATCH] SCSI host numbering messed up by reloading driver
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Baron
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-16 10:23 EST by Martin Wilck
Modified: 2013-03-06 00:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:23:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
UNTESTED patch that should give you the idea (1.15 KB, patch)
2004-03-16 10:24 EST, Martin Wilck
no flags Details | Diff

  None (edit)
Description Martin Wilck 2004-03-16 10:23:40 EST
Description of problem:

When loading/unloading SCSI drivers according to the following scheme:

a) load driver A
b) unload driver A
c) load driver B
d) load driver A

SCSI host numbers are messed up. Assuming that there are no other
hosts in the system and each driver detects obe host, bost hosts of
driver A and B will get host number 0.

/proc/scsi/scsi will show two devices with identical /host/bus/id/lun
if there are devices with the same bus/id/lun connected to the two hosts.

Not surprisingly, this causes trouble.

The scenario above may at first seem unlikely to happen in the real
world. Unfortunately it happens in a pretty common case: 
During installation of QU3 if a driver disk is needed and USB devices
are used for floppy/CD drives.

Version-Release number of selected component (if applicable):
All until 2.4.9-e.38.

How reproducible:
Always

Steps to Reproduce:
1.Install RedHat AS2.1 QU3 on a system with SCSI controller and USB
floppy, using a driver disk for the SCSI controller
2. The system will load usb-storage in order to access the driver
disk, copy the driver disk contents into the RAM disk, unload
usb-storage, load the SCSI driver, and reload usb.storage.
  
Actual results:
Both the SCSI driver and "usb-storage-0" have SCSI host number 0
("scsi0").

Expected results:
SCSI driver and usb-storage-0 have distinct host numbers.

Additional info:
The error is in line 157 of drivers/scsi/hosts.c in te function
scsi_register() (see HERE below). 

    for (shn = scsi_host_no_list;shn;shn = shn->next) {
        if (!(shn->host_registered) &&
            (hname_len > 0) && (0 == strncmp(hname, shn->name,
hname_len))) {
            flag_new = 0;
            retval->host_no = shn->host_no;  /* <<<< HERE */
            shn->host_registered = 1;
            shn->loaded_as_module = 1;
            break;
        }
    }

It is silently assumed that the old host_no has not been given to
another host in the meantime. In the scenario described above, though,
this is wrong.

I am attaching a small patch I just wrote to show how I think the
problem could be fixed. The patch is UNTESTED though.
Comment 1 Martin Wilck 2004-03-16 10:24:55 EST
Created attachment 98571 [details]
UNTESTED patch that should give you the idea
Comment 5 Martin Wilck 2005-02-01 08:42:46 EST
AFAICT this error persists in AS2.1 U5 and U6. 
Comment 6 Martin Wilck 2005-02-01 08:44:42 EST
It appears that there have been comments that I can't see (comment
#2,#3,#4). Would you mind making them visible to me?

As it stands, I have the impression that nobody ever looked at this.
Comment 7 Jason Baron 2005-02-07 15:33:55 EST
Patch looks sane to us, has it been tested at all?
Comment 8 RHEL Product and Program Management 2007-10-19 15:23:04 EDT
This bug is filed against RHEL2.1, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products.  Since
this bug does not meet that criteria, it is now being closed.

For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/

If you feel this bug is indeed mission critical, please contact your
support representative.  You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.