Bug 428143 - rtnetlink userland API change mid-release; 2.6.18-52 -> 2.6.18-59
Summary: rtnetlink userland API change mid-release; 2.6.18-52 -> 2.6.18-59
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.2
Hardware: All
OS: Linux
high
high
Target Milestone: beta
: ---
Assignee: Neil Horman
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-09 15:33 UTC by Lon Hohberger
Modified: 2008-05-21 15:06 UTC (History)
5 users (show)

Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 15:06:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
APIs that were removed from .52 -> .63 (1.73 KB, patch)
2008-01-09 15:33 UTC, Lon Hohberger
no flags Details | Diff
Patch assuming if_addr.h is moved to kernel-headers from kernel-devel (479 bytes, patch)
2008-01-09 19:31 UTC, Lon Hohberger
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0314 0 normal SHIPPED_LIVE Updated kernel packages for Red Hat Enterprise Linux 5.2 2008-05-20 18:43:34 UTC

Description Lon Hohberger 2008-01-09 15:33:38 UTC
Description of problem:  See attached.

diff is for /usr/include/linux/rtnetlink.h between 2.6.18-52.el5 and 2.6.18-63.el5

The changes (removing the address/interface information structures) breaks
various components of clustering, and prevents us from building for 5.2.

Comment 1 Lon Hohberger 2008-01-09 15:33:38 UTC
Created attachment 291165 [details]
APIs that were removed from .52 -> .63

Comment 2 Lon Hohberger 2008-01-09 15:45:36 UTC
Doing some research, these definitions were moved to if_addr.h (2.6.19-ish
timeframe?), which also isn't installed as part of the kernel-headers package.

(Userspace apps shouldn't be made to change #includes mid-lifecycle anyway.)

Comment 3 RHEL Program Management 2008-01-09 15:46:54 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Comment 5 Lon Hohberger 2008-01-09 15:48:03 UTC
(or at least the part removing the bits from rtnetlink.h)

Comment 8 Lon Hohberger 2008-01-09 18:19:49 UTC
https://bugzilla.redhat.com/attachment.cgi?id=291177

Possible patch.

Comment 9 Lon Hohberger 2008-01-09 18:21:28 UTC
Alternatively, provide #ifaddr.h in the kernel-headers RPM and possibly:

#ifndef __KERNEL__
#include <linux/if_addr.h>
#endif



Comment 10 Neil Horman 2008-01-09 18:54:05 UTC
Lon, IIRC if_addr.h is already included in the kernel-headers rpm.  You should
be able to add the code from comment 9 to rtnetlink.h and restore the missing
function. If you can confirm that fixes your abi break, I'll post that solution
ASAP.  Thanks!

Comment 11 RHEL Program Management 2008-01-09 18:57:20 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 12 Lon Hohberger 2008-01-09 18:59:08 UTC
Hi Neil, it's not in -65:

[lhh@ayanami magma]$ rpm -ql kernel-headers | grep if_addr
[lhh@ayanami magma]$ echo $?
1
[lhh@ayanami magma]$ rpm -q kernel-headers
kernel-headers-2.6.18-65.el5

If it makes a difference, my desktop is x86_64.

Comment 13 Lon Hohberger 2008-01-09 19:08:49 UTC
Seems that if_addr.h is in the kernel-devel package but needs to be in
kernel-headers package.  I'll move if_addr.h from
/src/kernels/2.6.18-65.el5-x86_64/include/linux and see if the simple workaround
works if I put it in /usr/include/linux.



Comment 14 Lon Hohberger 2008-01-09 19:12:26 UTC
[root@ayanami linux]# rpm -qf /usr/include/linux/rtnetlink.h
kernel-headers-2.6.18-65.el5

Moving if_addr.h from /usr/src/kernels/`uname -r`/include/linux to
/usr/include/linux and:

#ifndef __KERNEL__
#include <linux/if_addr.h>
#endif

... allowed me to build locally.

Comment 15 Lon Hohberger 2008-01-09 19:31:37 UTC
Created attachment 291190 [details]
Patch assuming if_addr.h is moved to kernel-headers from kernel-devel

Comment 16 Neil Horman 2008-01-10 00:31:21 UTC
Lon,  et al.

You can find kernel and kernel header packages containing a fix for this problem
in brew, under:
,.../brewroot/scratch/nhorman/task_1103120

Please test them out and confirm that your previously broken builds build
properly again.  The kernel-headers package is what you will need.  Thanks!

Comment 17 Jan Safranek 2008-01-11 08:40:04 UTC
net-snmp package has similar problems with moving IFA_PAYLOAD to unpackaged
if_addr.h. I tried compile with your
kernel-headers-2.6.18-65.el5.bz428143.x86_64.rpm, which resulted in confusing
errors. After some investigation I found problem at if_addr.h:53:

#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg)
There is a missing closing bracket at the end of the line      ^. How did you
build the kernel with such syntax error???

Compilation of net-snmp succeeds if I add the closing bracket. I would
appreciate if fixed kernel-headers would appear in brew buildroot ASAP, RHEL5.2
user space deadline is at Jan 18 and I'd like some time for tests :) - thanks in
advance.

Comment 18 Neil Horman 2008-01-11 11:43:31 UTC
regarding the failure, thats easy, the kernel doesn't use those macros, and as
such it was never instantiated in post-porcessed code, so no opportunity ever
arocse for the compiler to check it.  Since you confirmed that it worked, I'll
fix that oversight and post at once.


Comment 19 Jan Safranek 2008-01-11 12:34:50 UTC
(In reply to comment #18)
> Since you confirmed that it worked, I'll fix that oversight and post at once.

Please note that I am not original reporter, I wrote that it works for net-snmp,
cluster guys may have different opinion.



Comment 20 Lon Hohberger 2008-01-11 16:02:02 UTC
Neil - 

Confirmed

* rebuilt openais w/o errors:

cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -DOPENAIS_LINUX -I../include -fPIC
 -fPIC -c -o totemip.o totemip.c

^^ was failing here; no warnings or errors.  ;)

* rebuilt fence_xvm / fence_xvmd w/o errors
* tested fence_xvm + fence_xvmd - works; I didn't test on your test kernel -
only on a rebuild w/ the new headers.  I'm assuming that since the type sizes
didn't change in the headers that they didn't change in the newer kernel either.

Last test will be ensuring Anaconda builds, but I think it needs to be pushed
before that will even be possible (not sure).


Comment 21 Chris Lumens 2008-01-11 17:23:46 UTC
> Last test will be ensuring Anaconda builds, but I think it needs to be pushed
> before that will even be possible (not sure).

The easiest way for me is to have the new kernel packages in a buildroot so I
can do a scratch build of anaconda against it.

Comment 22 Neil Horman 2008-01-11 17:52:14 UTC
As an alternative you can get the dist-5E-qu-candidate mock-config from brew,
make a local buildroot with mock, and update to the test kernel-headers rpm
there for a scratch build.

Comment 24 Chris Lumens 2008-01-17 16:10:38 UTC
Which kernel package version should I be waiting on before I can rebuild anaconda?

Comment 28 Don Zickus 2008-01-21 17:30:31 UTC
in 2.6.18-71.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 30 Mike Gahagan 2008-02-29 21:36:16 UTC
verified that /usr/include/linux/if_addr.h is in the kernel-headers package 
for the -83.el5 kernel... also was able to sucessfully rebuild the net-snmp 
package.


Comment 32 errata-xmlrpc 2008-05-21 15:06:01 UTC
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/RHBA-2008-0314.html



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