Bug 128690 (IT_44687) - block_commit_write() not exported in RHEL 3
Summary: block_commit_write() not exported in RHEL 3
Alias: IT_44687
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
Depends On:
Blocks: 123574
TreeView+ depends on / blocked
Reported: 2004-07-28 02:40 UTC by Karen Bennet
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 20:55:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:550 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 4 2004-12-20 05:00:00 UTC

Description Karen Bennet 2004-07-28 02:40:08 UTC
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 15:08:59 UTC
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 17:44:09 UTC
A patch for this problem has been sent to rhkernel-list for consideration.


Comment 6 Ernie Petrides 2004-09-23 06:49:05 UTC
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 20:55:47 UTC
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.


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