Bug 129134 - Request to have the function revalidate_scsidisk() exported for 64-bit RHEL 3.0 platforms, ie. IA64, AMD64, EM64T.
Summary: Request to have the function revalidate_scsidisk() exported for 64-bit RHEL 3...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Ernie Petrides
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-04 12:25 UTC by Heather Conway
Modified: 2007-11-30 22:07 UTC (History)
9 users (show)

Clone Of:
Last Closed: 2004-09-10 20:23:57 UTC

Attachments (Terms of Use)

Description Heather Conway 2004-08-04 12:25:50 UTC
Description of problem:
This is a request to have the function revalidate_scsidisk() exported 
for 64-bit RHEL 3.0 platforms, ie. IA64, AMD64, EM64T.  This function 
is exported by default on IA32.  

Request =Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Arjan van de Ven 2004-08-04 12:28:50 UTC
"This function is exported by default on IA32"

Actually it appears to not be exported on ia32 either.

Which (GPL) module needs this export ?

Comment 2 Heather Conway 2004-08-04 18:27:43 UTC
You are correct.  It isn't exported on IA32 either.  
The module being worked with is PowerPath which isn't GPLd.  

Comment 3 Lucio DiGiovanni 2004-08-05 17:03:42 UTC
The symbol was exported previously in Update 2 for ia32. This is no 
longer the case with Update 3.

I'd like to better understand how RedHat determines which symbols get 

(From Jeff)


Comment 4 Ernie Petrides 2004-08-05 22:15:01 UTC
According to my source trees, revalidate_scsidisk() was never
exported at any time in RHEL3 (nor in RHEL2.1).  Currently, it
is the policy of Red Hat when introducing exports of symbols
for use in modules to use the EXPORT_SYMBOL_GPL() macro.  But
this would not be of use to PowerPath, since it's not GPL'ed.

Comment 5 Tim Burke 2004-08-06 05:27:13 UTC
If EMC can show that this symbol was exported previously in upstream
2.4 or 2.6 that makes things a lot simpler. If it has never been
exported, then we would need to get the acceptance from the upstream
SCSI subsystem maintainers.  Which would require a convincing argument
of the generic benefits and rationale.

Not trying to be difficult here, but merely pointing out our legal
obligations that we can't just arbitrarily export whatever symbols we

So we need the background info to come up with a compelling rationale.

Comment 7 Tim Burke 2004-08-06 05:36:54 UTC
Just curious.... why is this x86-64 specific?  What lead you to think
that things worked fine without the export for x86 previously?  Is the
real request to export it across the board?

The above comments on general benefit/justification still hold, just
trying to better understand the request.

Comment 8 Lucio DiGiovanni 2004-08-06 16:54:23 UTC
The symbol was somehow exported implicitly on update 2 and earlier 
kernels. That changed with update 3, which breaks PowerPath (see 
output from ksyms below). We'd like to find out what changes prompted 
this behavior. 


update 3

[root@lcld0084 root]# uname -a
Linux lcld0084 2.4.21-18.ELsmp #1 SMP Thu Jul 22 15:12:08 EDT 2004 
i686 i686 i38
6 GNU/Linux
[root@lcld0084 root]# ksyms -a|grep revalidate_scsidisk
[root@lcld0084 root]#

update 2

[root@lca0093 root]# uname -a
Linux lca0093 2.4.21-15.0.3.ELhugemem #1 SMP Tue Jun 29 17:49:15 EDT 
2004 i686 i
686 i386 GNU/Linux
[root@lca0093 root]# ksyms -a|grep revalidate_scsidisk
8282e2a0  revalidate_scsidisk               [sd_mod]
[root@lca0093 root]#

(From David)

Comment 9 Ernie Petrides 2004-08-06 22:13:14 UTC
I have tracked this down to a quirk of the "insmod" command.  The
symbol in question was *never* explicitly exported.  However, when
a module is built without any explicit exports, "insmod" by default
exports *every* non-static symbol of the module (unless the "-x"
option is used).

Prior to U3, revalidate_scsidisk() was "accidentally" exported
without any module versioning checksum (along with hundreds of
symbols from other modules) due to its associated source file
(drivers/scsi/sd.c) not having any explicitly exported symbols.

In U3, a new explicitly exported routine was added to this source
file in support of diskdump (and drivers/scsi/Makefile was changed
to add sd.o to the "export-objs" list).  The "insmod" command now
exports the new symbol (sd_find_scsi_device), but no longer exports
the old one (revalidate_scsidisk).

I've also just checked Upstream: revalidate_scsidisk() exists in
2.4.26 as a non-exported symbol, but it does not exist in 2.6.7.

Cheers.  -ernie

Comment 12 Tim Burke 2004-08-10 00:47:17 UTC
A question for EMC....

This is a tough issue.  Reason being, that revalidate_scsidisk() was
never part of the officially supported kernel symbols exported in
RHEL3.  It is not included in the official KMI which are EXPORT_SYMBOL
and EXPORT_SYMBOL_GPL tagged.  Its not modversions protected. Rather
through a side effect of insmod was it previously available.  Here's why:

If there are *no* symbols in a module which are EXPORT_SYMBOL or
EXPORT_SYMBOL_GPL tagged then a quirk of the insmod command is to end
up exporting all symbols in the module.  This is how
revalidate_scsidisk() got exposed.

Then in U3, a legitimate export was added to a file in this same
module.  The end result is that only this one single new export is
provided.  All the prior ones previously exported as a side effect are
no longer exported.

What to do about it?
1) Try to find an alternative approach that EMC can use to accomplish
the desired capability.  More on this in the next comment update.

2) Mark the requested symbol as EXPORT_SYMBOL_GPL.  This would be
useless from an EMC perspective.

3) Mark the symbol as EXPORT_SYMBOL.  This would be the ideal option
from an EMC perspective.  As mentioned above in comment #5, we can't
just arbitrarily add symbols for legal reasons (yes there have been
real issues in the recent past).  In order for us to add exports
(expecially for cases where the export isn't upstream) we need the
concent of the respective subsystem maintainer(s).  In order to get
something EXPORT_SYMBOL we need to demonstrate its generic usefulness
to non-GPL as well as GPL consumers.  Especially when it comes to
interfaces for binary drivers, the prospects for concent are bleak.

Comment 13 Tim Burke 2004-08-10 00:50:41 UTC
The following is an excerpt from an interinal IRC session where a
possible alternative approach is discussed. The intention is to find a
means for powerpath to get the job done using other officially
exported kernel interfaces.

> the function is already _sort_ of exported ---
> For any scsi block device, the block_device_operations->revalidate()
call in turn calls revalidate_scsidisk() with second arg 0
> and a BLKRRPART ioctl() calls it with second arg 1 (and this should
be the only case where that is needed)

Comment 14 Tim Burke 2004-08-10 01:14:30 UTC
Another translation of above recomendation:

There may well be a workaround for powerpath's use of
revalidate_scsidisk().  [Technically,
block_device_operations->revalidate(dev) is almost exactly equivalent;
revalidate_scsidisk() is only slightly more flexible and there's a good
chance that the difference between them is irrelevant to powerpath.]

Comment 15 Heather Conway 2004-08-10 12:07:24 UTC
Thanks Tim.  I'll forward your comments back to the PowerPath 
developers and will update the bugzilla again after discussing with 

Comment 16 Tim Burke 2004-08-10 18:09:29 UTC
Heather - our code freeze for RHEL3 U3 is noon tomorrow. So we're
under a major time crunch.  As mentioned above, its unlikely we can
push this through upstream.  But I want us working w/ EMC to ensure
that you can get by with other interfaces.

Comment 17 Heather Conway 2004-09-10 15:05:44 UTC
The issue appears to have been resolved with a change in PowerPath.
Closing the issue.

Comment 18 Ernie Petrides 2004-09-10 20:23:57 UTC
Reclosing as WONTFIX.

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