s390(64) per_cpu in modules (ipv6)

From: Pete Zaitcev (zaitcev_at_redhat.com)
Date: 06/30/04

  • Next message: Martin J. Bligh: "Re: remap_pte_range" 
    Date:	Tue, 29 Jun 2004 23:35:37 -0700
To: schwidefsky@de.ibm.com

    Hi, Martin,

    I tried to build ipv6 as a module in 2.6.7, and it bombs, producing a
    module which wants per_cpu____icmpv6_socket (obviously, undefined).

    The problem appears to be caused by this:

    #define __get_got_cpu_var(var,offset) \
      (*({ unsigned long *__ptr; \
           asm ( "larl %0,per_cpu__"#var"@GOTENT" : "=a" (__ptr) ); \
           ((typeof(&per_cpu__##var))((*__ptr) + offset)); \
        }))

    The net/ipv6/icmp.c has this:

    static DEFINE_PER_CPU(struct socket *, __icmpv6_socket) = NULL;

    It is a static variable, and all references to it come from asm code.
    The gcc does not know that they are present and optimizes the variable
    away. It simply emits no code to define per_cpu____icmpv6_socket
    whatsoever, as verified with gcc -S.

    If the DEFINE_PER_CPU() is used without static, or if a bogus
    reference is added to the C code (a printk), everything works.

    I tried to add a fake input argument to the asm, like this:

    --- linux-2.6.7-1.459/include/asm-s390/percpu.h 2004-06-16 01:20:04.000000000 -0400
    +++ linux-2.6.7-1.459.z1/include/asm-s390/percpu.h 2004-06-29 22:03:23.000000000 -0400
    @@ -15,7 +15,7 @@
     #if defined(__s390x__) && defined(MODULE)
     #define __get_got_cpu_var(var,offset) \
       (*({ unsigned long *__ptr; \
    - asm ( "larl %0,per_cpu__"#var"@GOTENT" : "=a" (__ptr) ); \
    + asm ( "larl %0,per_cpu__"#var"@GOTENT" : "=a" (__ptr) : "a" (&per_cpu__##var) ); \
            ((typeof(&per_cpu__##var))((*__ptr) + offset)); \
         }))
     #undef __get_cpu_var

    It seems to work fine, but I'm wondering if a better fix can be found.
    Ideas?

    -- Pete
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Martin J. Bligh: "Re: remap_pte_range"

    Relevant Pages

    • Re: [PATCH] Fix NR_KEYS off-by-one error
      ... > larger types (short or int, ... Probably gcc not warn, I think. ... > You are absolutely correct that overhead is insignificant. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • oops when copying from IDE CD
      ... gcc version 3.3.2 20030908 ... I haven't got any experience in reporting kernel panics, ... send the line "unsubscribe linux-kernel" in ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • Re: Problems Building Bluetooth with K6 and CONFIG_REGPARM
      ... >>Hi Andy, ... > Sounds like a compiler bug, especially since changing the CPU type fixes ... I was using Debian's GCC 4.0.1-6. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the
      ... You're oversimplifying a little, though. ... and it unregisters everything it has registered, and all those references ... synchronous or it supplies a callback which does the actual kfree. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: drivers/block/ub.c
      ... >> Unless I am mistaken, this structure is transfered as such over the bus, ... > It is needed only if the structure elements are such that gcc will ... > not packet them properly on all supported architecutures. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)