Bug 493239

Summary: Uni-processor build fails due to duplicate symbols
Product: Red Hat Enterprise Linux 5 Reporter: Steve Snyder <swsnyder>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED DUPLICATE QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: ajb, bnagendr, dzickus, emcnabb, hpicht, newideas.it, peterm, revers, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-29 12:56:59 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: 533192    
Attachments:
Description Flags
#ifdef set_cpus_allowed_ptr() to CONFIG_SMP
none
Updated to #ifdef more code that should be SMP-only
none
RHEL5 initial patch for this issue
none
RHEL5 patch none

Description Steve Snyder 2009-04-01 02:57:32 UTC
Created attachment 337429 [details]
#ifdef set_cpus_allowed_ptr() to CONFIG_SMP

Description of problem:

When building the kernel without SMP support, the build fails due to duplicate symbols.  One of the definitions of set_cpus_allowed_ptr() is little more that a stub.  The other seems to be for SMP.  It should be #igdef'd to CONFIG_SMP, but is not.

Version-Release number of selected component (if applicable):

kernel-2.6.18-128.1.1.el5

How reproducible:

Always

Steps to Reproduce:
1. "rpm -ivh kernel-2.6.18-128.1.1.el5.src.rpm"
2. "rpmbuild -bp -target i686 /usr/src/redhat/SPEC/kernel.spec"
3. Using "make menuconfig" disable the SMP option; attempt to build
  
Actual results:

kernel/sched.c:1388: error: redefinition of ‘set_cpus_allowed_ptr’
include/linux/sched.h:1167: error: previous definition of ‘set_cpus_allowed_ptr’ was here
kernel/sched.c: In function ‘set_cpus_allowed_ptr’:
kernel/sched.c:1389: error: storage size of ‘req’ isn’t known
kernel/sched.c:1406: error: implicit declaration of function ‘migrate_task’
kernel/sched.c:1409: error: ‘struct rq’ has no member named ‘migration_thread’
kernel/sched.c:1389: warning: unused variable ‘req’
kernel/sched.c: At top level:
kernel/sched.c:4033: warning: ‘interruptible_sleep_on’ is deprecated (declared at kernel/sched.c:4022)
kernel/sched.c:4033: warning: ‘interruptible_sleep_on’ is deprecated (declared at kernel/sched.c:4022)
kernel/sched.c:4067: warning: ‘sleep_on_timeout’ is deprecated (declared at kernel/sched.c:4053)
kernel/sched.c:4067: warning: ‘sleep_on_timeout’ is deprecated (declared at kernel/sched.c:4053)
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
make: *** Waiting for unfinished jobs....


Expected results:

The code should be buildable when configured with the kerlen config system.

Additional info:

The attached patch seems to fix it.

Comment 1 Steve Snyder 2009-04-01 03:01:32 UTC
Forgot to add standard disclaimer: I know that Red Hat doesn't support user-modified kernel configurations.  Nevertheless I suspect you will want to know that the build is easily broken in the course of using the standard Linux configuration system.

Comment 2 Prarit Bhargava 2009-04-01 12:33:01 UTC
(In reply to comment #1)
> Forgot to add standard disclaimer: I know that Red Hat doesn't support
> user-modified kernel configurations.  Nevertheless I suspect you will want to
> know that the build is easily broken in the course of using the standard Linux
> configuration system.  

Hi Steve,

:)

Exactly, but this seems like a pretty simply fix and, frankly, it should compile.

P.

Comment 3 Steve Snyder 2009-04-01 13:15:46 UTC
Updated patch cures this too:

kernel/built-in.o: In function `sched_init':
/usr/src/linux-2.6.18-128.1.1.el5.sws/kernel/sched.c:7114: undefined reference to `arch_update_cpu_topology'
make: *** [.tmp_vmlinux1] Error 1

In this case arch_update_cpu_topology() is unconditionally referenced in sched.c.  The actual function is in topology.c which built conditionally on CONFIG_SMP.  There seems to be a dummy arch_update_cpu_topology() also in sched.c but it is not found by the linker.  Probably #ifdef'd out in compilation (it's hard to follow all those nested #ifdefs).

Comment 4 Steve Snyder 2009-04-01 13:17:46 UTC
Created attachment 337509 [details]
Updated to #ifdef more code that should be SMP-only

Comment 5 Prarit Bhargava 2009-04-01 18:51:55 UTC
Created attachment 337613 [details]
RHEL5 initial patch for this issue

Steve, this patch should resolve your build problems.  It is not, however, a final patch.  This code does not appear to be necessary upstream which leads me to believe that something else is missing.

(But this will at least get you compiling with CONFIG_SMP off)

P.

Comment 7 Prarit Bhargava 2009-04-02 14:32:55 UTC
Created attachment 337825 [details]
RHEL5 patch

Comment 8 Prarit Bhargava 2009-04-02 14:35:11 UTC
Rob, the above patch contains simple patches for 4 files.  The two you need to take a look at with Emulex are,

drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c

and

drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c

Neither of these files will compile if CONFIG_SMP is turned off.

Could we either a) get Emulex to sign off on the patch, or b) request that Emulex include this patch in their next release?

Thanks,

P.

Comment 9 Rob Evers 2009-04-03 16:27:03 UTC
Hi Prarit,

These changes have nothing to do w/ Emulex, they are in generic fc libfc code.
Given that, there is no interaction w/ Emulex required.  Post the patch as-is.

Please make sure that it builds all w/ brew-build.

BTW, should brew-build  be updated to build uni-processor to avoid problems like this in the future?

Rob

Comment 10 Prarit Bhargava 2009-04-03 17:06:11 UTC
(In reply to comment #9)
> Hi Prarit,
> 
> These changes have nothing to do w/ Emulex, they are in generic fc libfc code.
> Given that, there is no interaction w/ Emulex required.  Post the patch as-is.
> 
> Please make sure that it builds all w/ brew-build.
> 

Will do.

> BTW, should brew-build  be updated to build uni-processor to avoid problems
> like this in the future?

Nope, RH does not ship a RHEL5 UP kernel.  Having said that, it should still compile if CONFIG_SMP is not set.

P.

Comment 11 Steve Snyder 2009-05-08 13:40:14 UTC
FYI, I can confirm that Prarit Bhargava's 02 Apr 2009 patch ("RHEL5 patch") works correctly on kernel 2.6.18-128.1.10.el5.

(In reply to comment #7)
> Created an attachment (id=337825) [details]
> RHEL5 patch  

FYI, I can confirm that this patch works correctly on kernel 2.6.18-128.1.10.el5.

Comment 13 RHEL Program Management 2009-09-25 17:35:42 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 16 Jai 2010-08-10 09:45:14 UTC
Hi,

   I also want to run Uniprocessor machine in Cent os 5.4.As expected I got the error as like Steve, so  modified the above patch little and tried to use it in kernel-2.6.18-164.11.1.el5.src.rpm but I ended with different error 

drivers/scsi/fcoe/fcoe.c: In function 'fcoe_init':
drivers/scsi/fcoe/fcoe.c:1842: error: expected expression before 'do'
make[3]: *** [drivers/scsi/fcoe/fcoe.o] Error 1

Not sure how to fix it . Any little help will be a big one for me.

Thanks in Advance,
jai

Comment 17 Steve Snyder 2010-08-10 11:19:41 UTC
(In reply to comment #16)
> Hi,
> 
>    I also want to run Uniprocessor machine in Cent os 5.4.As expected I got the
> error as like Steve, so  modified the above patch little and tried to use it in
> kernel-2.6.18-164.11.1.el5.src.rpm but I ended with different error 
> 
> drivers/scsi/fcoe/fcoe.c: In function 'fcoe_init':
> drivers/scsi/fcoe/fcoe.c:1842: error: expected expression before 'do'
> make[3]: *** [drivers/scsi/fcoe/fcoe.o] Error 1
> 
> Not sure how to fix it . Any little help will be a big one for me.
> 
> Thanks in Advance,
> jai    

I believe that the patch for Bug 526708 fixes this.

Comment 18 Jai 2010-08-11 15:46:03 UTC
A big thanks Steve .. It got compiled after including the above patch 526708 ...

Thanks,
Jai

Comment 19 Prarit Bhargava 2010-09-29 12:56:59 UTC

*** This bug has been marked as a duplicate of bug 526708 ***