Bug 128690 (IT_44687)

Summary:	block_commit_write() not exported in RHEL 3
Product:	Red Hat Enterprise Linux 3	Reporter:	Karen Bennet <bennet>
Component:	kernel	Assignee:	Larry Woodman <lwoodman>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	aviro, dledford, petrides, riel, tao, tburke
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-12-20 20:55:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	123574

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.

Larry

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.

http://rhn.redhat.com/errata/RHBA-2004-550.html