Bug 504593 - LRO patch to 4.7 breaks SANGOMA WANPIPE drivers build
LRO patch to 4.7 breaks SANGOMA WANPIPE drivers build
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.8
All Linux
low Severity medium
: rc
: ---
Assigned To: Neil Horman
Evan McNabb
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-08 08:35 EDT by Laurent Jean-Rigaud
Modified: 2011-02-16 11:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-16 11:05:41 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)
patch to properly define __bitwise (769 bytes, patch)
2009-07-01 07:03 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Laurent Jean-Rigaud 2009-06-08 08:35:19 EDT
Description of problem:

The patch linux-2.6.9-ehea-Fixes-to-make-LRO-compile-in-RHEL-4.7.patch (-ehea: Fixes to make LRO compile in RHEL 4.7 (Ed Pollard) [300201]) adds new types in include/linux/types. These broke SANGOMA wanpipe driver build under x86_64 platforms (i386 not tested).


Version-Release number of selected component (if applicable):
2.6.9-89.EL (since 2.6.9-68.26 in fact)

How reproducible:

build sangoma wanpipe modules&tools

Steps to Reproduce:
1. download wanpipe Linux tools (drivers and userland tools) for Sangoma X.25 cards.
2. build again kernel-devel sources
3. process failed with following errors :
  

Actual results:
../..
make[1]: Entering directory `/home/buildsys/wanpipe/wanpipe-3.1.0-b1/util/wanec_client'
yacc -d wan_ec_arg.y
lex     -owan_ec_argl.c wan_ec_arg.l
gcc -Wall -O2 -D__LINUX__ -DCONFIG_PRODUCT_WANPIPE_TDMV_EC -D_DEBUG_=2 -D_GNUC_ -I/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include -I../../patches/kdrivers/wanec -I../../patches/kdrivers/include  -I../../patches/kdrivers/wanec/oct6100_api/include  -I../wanec_apilib  -o wan_ec_client wan_ecmain.c y.tab.c wan_ec_argl.c ../wanec_apilib/wanec_api.c ../wanec_apilib/wanec_api_lib.c
In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22,
                 from wan_ecmain.c:35:
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class
wan_ec_argl.c:1093: warning: 'yyunput' defined but not used
In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22,
                 from ../wanec_apilib/wanec_api.c:35:
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class
In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22,
                 from ../wanec_apilib/wanec_api_lib.c:35:
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum"
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum'
/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class
make[1]: *** [wan_ec_client] Error 1
make[1]: Leaving directory `/home/buildsys/wanpipe/wanpipe-3.1.0-b1/util/wanec_client'
make: *** [all] Error 2
../..


Expected results:
compile w/o errors (we used w/o problem 2.6.9-57.EL before).


Additional info:
Problem seems to be the following addon:

diff -uNr /usr/src/kernels/2.6.9-57.EL-smp-x86_64/include/linux/types.h /usr/src/kernels/2.6.9-89.EL-smp-x86_64/include/linux/types.h
--- /usr/src/kernels/2.6.9-57.EL-smp-x86_64/include/linux/types.h     2004-10-18 23:55:06.000000000 +0200
+++ /usr/src/kernels/2.6.9-89.EL-smp-x86_64/include/linux/types.h 2009-06-08 14:23:31.000000000 +0200
@@ -155,6 +155,9 @@
 
 #endif /* __KERNEL_STRICT_NAMES */
 
+typedef __u16 __bitwise __sum16;
+typedef __u32 __bitwise __wsum;
+
 /*
  * Below are truly Linux-specific types that should never collide with
  * any application/library that wants linux/types.h.


This typedefs came with LRO patches in 68.26 release. It seems the typedefs should be added just 3 lines before, before the "#endif /* __KERNEL_STRICT_NAMES */".

Actually, this solution corrects the problem but should it applicable for everyone ?
Comment 1 Neil Horman 2009-07-01 07:03:16 EDT
Created attachment 350084 [details]
patch to properly define __bitwise

Yep, looks like we don't define __bitwise in the right place.  Please test with this patch.  You can either apply it to the kernel sources, build it and install the new kernel and kernel-headers package, or you should be able to manually apply it to the in-place include file that you have now.  Let me know how it goes and I'll post it for inclusion.  Thanks!
Comment 2 Laurent Jean-Rigaud 2009-07-01 08:44:47 EDT
Hi,

According to me, it would be better to move the 2 new defines some line ealier than move the __bitwise block at the beginning of file, as it is close at the same place than in last 2.6.30/31.

The problem is set by linux-2.6.9-ehea-Fixes-to-make-LRO-compile-in-RHEL-4.7.patch :

@@ -155,6 +155,9 @@ typedef __u64 __bitwise __be64;

 #endif /* __KERNEL_STRICT_NAMES */

+typedef __u16 __bitwise __sum16;
+typedef __u32 __bitwise __wsum;
+
 /*
  * Below are truly Linux-specific types that should never collide with
  * any application/library that wants linux/types.h.

Just modifying it (typedef before the __KERNEL_STRICT_NAMES endif corrects the problem and keeps the 'littlely modified by 1970 patchfiles' 2.6.9 sources more closed to vanilla's ones. ;-)

As we used a patched kernel for sangoma drivers that satisfy ours internal tests, i can not take time now to rebuild one with your patch version (no time before holidays). I could done this in 3 weeks, with updated vgoyal's kernel srpms (if the RH team don't take some holidays too ;-)).
 

Regards
Comment 3 Neil Horman 2009-07-01 09:31:44 EDT
Thats not in line with upstream, and my way is safer.  __sum16 and __wsum are defined regardless of weather or not __KERNEL_STRICT_NAMES is undefined.  If someone builds a kernel with the state of that define toggled, we loose those definitions, and the kernel can break.  Upstream has removed the __KERNEL_STRICT_NAMES define from types.h entirely, but I can't safely do that in RHEL, so instead we move the CHECKER definition tobe global in scope rather than only defined for the strict names

Please test the patch as is.
Comment 4 Laurent Jean-Rigaud 2009-07-01 12:37:00 EDT
Humm __KERNEL_STRICT_NAMES should be keep for libc5 compatibility, no ?

Btw do as you want.  
Also, I couldn't test it for 3 weeks but your patch should correct the problem.
Comment 5 Neil Horman 2009-07-01 13:25:17 EDT
yes, thats exactly what I'm saying.  We can't remove the STRICT_NAMES define in RHEL since we need to preserve compatibility.

You can't test this for three weeks?  Fine, I'll find some tie to do it.
Comment 6 RHEL Product and Program Management 2009-07-01 15:52:39 EDT
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 7 Vivek Goyal 2010-10-15 09:28:49 EDT
Committed in 89.44.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 10 errata-xmlrpc 2011-02-16 11:05:41 EST
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 therefore 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/RHSA-2011-0263.html

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