Bug 428143 - rtnetlink userland API change mid-release; 2.6.18-52 -> 2.6.18-59
rtnetlink userland API change mid-release; 2.6.18-52 -> 2.6.18-59
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
high Severity high
: beta
: ---
Assigned To: Neil Horman
Martin Jenner
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-09 10:33 EST by Lon Hohberger
Modified: 2008-05-21 11:06 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:06:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
APIs that were removed from .52 -> .63 (1.73 KB, patch)
2008-01-09 10:33 EST, 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 14:31 EST, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Lon Hohberger 2008-01-09 10:33:38 EST
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 10:33:38 EST
Created attachment 291165 [details]
APIs that were removed from .52 -> .63
Comment 2 Lon Hohberger 2008-01-09 10:45:36 EST
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 Product and Program Management 2008-01-09 10:46:54 EST
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 10:48:03 EST
(or at least the part removing the bits from rtnetlink.h)
Comment 8 Lon Hohberger 2008-01-09 13:19:49 EST
https://bugzilla.redhat.com/attachment.cgi?id=291177

Possible patch.
Comment 9 Lon Hohberger 2008-01-09 13:21:28 EST
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 13:54:05 EST
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 Product and Program Management 2008-01-09 13:57:20 EST
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 13:59:08 EST
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 14:08:49 EST
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 14:12:26 EST
[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 14:31:37 EST
Created attachment 291190 [details]
Patch assuming if_addr.h is moved to kernel-headers from kernel-devel
Comment 16 Neil Horman 2008-01-09 19:31:21 EST
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 03:40:04 EST
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 06:43:31 EST
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 07:34:50 EST
(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 11:02:02 EST
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 12:23:46 EST
> 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 12:52:14 EST
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 11:10:38 EST
Which kernel package version should I be waiting on before I can rebuild anaconda?
Comment 28 Don Zickus 2008-01-21 12:30:31 EST
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 16:36:16 EST
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 11:06:01 EDT
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.