Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162603 - dpt_i2o driver oopses on insmod in U5
Summary: dpt_i2o driver oopses on insmod in U5
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Brian Brock
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2005-07-06 19:36 UTC by Neil Horman
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-28 15:28:00 UTC
Target Upstream Version:

Attachments (Terms of Use)
patch to correct dereferencing of uninitalized NULL data. (deleted)
2005-07-06 19:36 UTC, Neil Horman
no flags Details | Diff
New version of patch, taking some suggestions from internal review into account. (deleted)
2005-07-08 13:52 UTC, Neil Horman
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:663 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 6 2005-09-28 04:00:00 UTC

Description Neil Horman 2005-07-06 19:36:30 UTC
Description of problem:
When installing the dpt_i2o driver in U5, the following oops is seen:
EIP is at vsnprintf [kernel] 0x2df (2.4.21-32.0.1.ELsmp/i686)
eax: 0000003e   ebx: 0000000a   ecx: 0000003e   edx: fffffffe
esi: c0480f6b   edi: 00000000   ebp: c048135f   esp: f773fe0c
ds: 0068   es: 0068   ss: 0068
Process modprobe (pid: 220, stackpage=f773f000)
Stack: c0480f67 c048135f 00000003 00000000 0000000a ffffffff 00000000 00000002
      ffffffff ffffffff f7f98540 00000046 c3988e47 f89572dd c01297ae c0480f60
      00000400 f881b30e f773fe74 f7f98540 f7758400 c3988e47 f880f320 f881b301
Call Trace:   [<f89572dd>] .rodata.str1.1 [dpt_i2o] 0x0 (0xf773fe40)
[<c01297ae>] printk [kernel] 0x7e (0xf773fe44)
[<f881b30e>] .rodata.str1.1 [scsi_mod] 0x2b6 (0xf773fe50)
[<f880f320>] scsi_setup_host [scsi_mod] 0x40 (0xf773fe64)
[<f881b301>] .rodata.str1.1 [scsi_mod] 0x2a9 (0xf773fe68)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773fe90)
[<f89572e4>] .rodata.str1.1 [dpt_i2o] 0x7 (0xf773fe98)
[<f8810c99>] scsi_register_Rsmp_4853a9b7 [scsi_mod] 0x299 (0xf773fe9c)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773febc)
[<f89540df>] adpt_scsi_register [dpt_i2o] 0x1f (0xf773fec8)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773fecc)
[<f89511ec>] adpt_detect [dpt_i2o] 0x15c (0xf773fed8)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773fee0)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773feec)
[<f880f5a1>] scsi_register_host [scsi_mod] 0x61 (0xf773fef0)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773fef4)
[<f8955e41>] init_this_scsi_driver [dpt_i2o] 0x21 (0xf773ff00)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773ff04)
[<f8958540>] driver_template_dump [dpt_i2o] 0x0 (0xf773ff08)
[<c012aeb6>] sys_init_module [kernel] 0x5b6 (0xf773ff0c)
[<f89577c4>] .kmodtab [dpt_i2o] 0x0 (0xf773ff20)
[<f8951060>] adpt_read_blink_led [dpt_i2o] 0x0 (0xf773ff2c)
[<f8957638>] __ksymtab [dpt_i2o] 0x0 (0xf773ff30)
[<f8951060>] adpt_read_blink_led [dpt_i2o] 0x0 (0xf773ff58)

Version-Release number of selected component (if applicable):
U5 (2.4.21-32+)

How reproducible:

Steps to Reproduce:
1.insmod dpt_i2o
Actual results:
kernel oops

Expected results:
successful instalation.

Additional info:
This problem stems from the fact that scsi_register calls scsi_setup_host, which
in turn calls a scsi hosts info method to retrieve a meaningful string to print
out during driver initalization as it finds HBAs. The problem is that the info
method uses the passed in host data, which is only partially initalized at this
point.  This causes it to return uninitalized data to scsi_setup_host which it
then dereferences.  The data does not get fully initalized until after
scsi_register completes, in adpt_scsi_register.  This patch removes the
adpt_info method from the driver template (as its just a vestige after driver
initalization anyway), and assigns a static driver name to the template instead,
preventing the oops.  This patch has been tested by the reporting customer with
successful results.

Comment 1 Neil Horman 2005-07-06 19:36:30 UTC
Created attachment 116428 [details]
patch to correct dereferencing of uninitalized NULL data.

Comment 3 Neil Horman 2005-07-08 13:52:34 UTC
Created attachment 116517 [details]
New version of patch, taking some suggestions from internal review into account.

Comment 5 Ernie Petrides 2005-07-16 00:23:48 UTC
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.12.EL).

Comment 9 Red Hat Bugzilla 2005-09-28 15:28:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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