Bug 128690 - (IT_44687) block_commit_write() not exported in RHEL 3
block_commit_write() not exported in RHEL 3
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: Larry Woodman
Brian Brock
:
Depends On:
Blocks: 123574
  Show dependency treegraph
 
Reported: 2004-07-27 22:40 EDT by Karen Bennet
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-20 15:55:47 EST
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 Karen Bennet 2004-07-27 22:40:08 EDT
block_commit_write() is not exported in RHEL 3, yet it is in 2.6.  It
is needed by OCFS2 because OCFS2 needs the loff_t version of
cont_prepare_write() from 2.6, and so has to implement
ocfs2_cont_prepare_write() for RHEL 3 systems.  As changing
cont_prepare_write() to take loff_t ala 2.6 is an ABI breakage, can we
just get block_commit_write() exported in the next errata (for all
architectures)?  If this can squeeze into RHEL 3 U3, that would be great.
----------
Action by: van
Issue Registered
----------
Action by: van
OCFS2 is scheduled to be released around the time Oracle 10g patchset
1 is released, which is roughly mid-Aug.  OCFS2 may not be supported
on RHEL 3 until this symbol gets exported.

Status set to: Waiting on Tech

----------
Action by: robinson
Checking into this.

robinson assigned to issue for Oracle IT.

Category set to: Applications

----------
Action by: robinson
Is this possible without breaking ABI? Can we request this for the
next Update? Justification is that it is nescesarry for OCFS2 to be
supported on RHEL 3.


Issue escalated to Support Engineering Group by: robinson
.
----------
Action by: wcheng
Need to get kernel folks to decide. 


Issue escalated to Sustaining Engineering by: wcheng
.wcheng assigned to issue for Support Engineering Group.
Comment 2 Alexandre Oliva 2004-07-31 11:08:59 EDT
Per conversation with Arjan, exporting symbols doesn't break the
kernel ABI, but if we add exports that aren't upstream, we do so with
EXPORT_SYMBOL_GPL, instead of EXPORT_SYMBOL, which is what kernel 2.6
uses to export this one symbol.  I'm not sure whether we should regard
this as a back-port of the EXPORT_SYMBOL, or as exporting a symbol
that was not exported in our baseline kernel.  Exporting as GPL would
be ok enough for OCFS2, but not for any non-GPLed users of this
symbol.  If you let me know the way to go, I'll be glad to post a
patch to help speed up the integration of the patch.  Thanks,
Comment 5 Larry Woodman 2004-09-15 13:44:09 EDT
A patch for this problem has been sent to rhkernel-list for consideration.

Larry
Comment 6 Ernie Petrides 2004-09-23 02:49:05 EDT
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.10.EL).
Comment 7 John Flanagan 2004-12-20 15:55:47 EST
An errata 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/RHBA-2004-550.html

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