Bug 137788 - Extraneous data in option name for scsi_mod
Extraneous data in option name for scsi_mod
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
Brian Brock
:
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2004-11-01 06:55 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 10:31:18 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)

  None (edit)
Description Bastien Nocera 2004-11-01 06:55:04 EST
Description of problem:
$ modinfo scsi_mod
filename:    /lib/modules/2.4.21-20.ELsmp/kernel/drivers/scsi/scsi_mod.o
description: "SCSI core"
author:      <none>
license:     "GPL"
parm:        scsi_logging_level_Rsmp_af3dd7dc int, description "SCSI
logging level; should be zero or nonzero"
parm:        scsihosts string
parm:        max_scsi_luns int, description "last scsi LUN (should be
between 1 and 2^32-1)"
parm:        scsi_allow_ghost_devices int, description "allow devices
marked as being offline to be accessed anyway (0 = off, else allow
ghosts on lun 0 through scsi_allow_ghost_devices - 1"

I don't think that "scsi_logging_level_Rsmp_af3dd7dc" is the real
parameter name.
Comment 1 Bastien Nocera 2004-11-01 06:58:06 EST
Reproduceable with the 2.4.21-22.EL SMP kernel, the UP kernel has a
similar bizarre parameter.
Comment 3 Doug Ledford 2005-03-01 03:08:53 EST
The problem is that the variable in question is both export as a
module parameter and also EXPORT_SYMBOL'ed to other modules so that
they can check the variable's value at runtime (done by the SCSI_LOG
macros).  Because the kernel has symbol versions enabled, a checksum
gets added to the symbol name and that shows up in the module
parameter name as well.  The fix for this is simple, just
EXPORT_SYMBOL_NOVERS() the symbol instead.  However, technically,
that's breaking kABI and I don't know if any external vendor modules
already rely upon the broken symbol name.  I submitted a patch for
review, but the decision on whether or not to even consider including
the patch will depend upon the kABI issue.

Note: the patch was submitted post the U5 deadline and is therefore
not expected in U5, but it's now posted and if it gets approved, is
already in the queue for U6.
Comment 4 Ernie Petrides 2005-03-02 15:14:03 EST
Reverting to ASSIGNED state until a fix is committed to CVS.
Comment 5 Ernie Petrides 2005-04-27 23:26:21 EDT
Non-kABI-breaking alternative patch posted for review by petrides
on 25-Apr-2005, now queued for next U6 build.
Comment 6 Ernie Petrides 2005-05-04 20:35:32 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.3.EL).
Comment 14 Red Hat Bugzilla 2005-09-28 10:31:18 EDT
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.

http://rhn.redhat.com/errata/RHSA-2005-663.html

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