From: Greg KH <gregkh@linuxfoundation.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>,
linux-kernel@vger.kernel.org,
Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH] staging: ram_console: Fix section mismatches
Date: Thu, 8 Mar 2012 10:43:20 -0800 [thread overview]
Message-ID: <20120308184320.GA29273@kroah.com> (raw)
In-Reply-To: <4F58FBA6.60509@codeaurora.org>
On Thu, Mar 08, 2012 at 10:34:14AM -0800, Stephen Boyd wrote:
> On 03/08/12 10:23, Greg KH wrote:
> > On Thu, Mar 08, 2012 at 10:12:07AM -0800, Stephen Boyd wrote:
> >> On 03/08/12 09:56, Greg KH wrote:
> >>> On Thu, Mar 08, 2012 at 01:08:04AM -0800, Stephen Boyd wrote:
> >>>> WARNING: vmlinux.o(.text+0x25d5fc): Section mismatch in reference
> >>>> from the function ram_console_driver_probe() to the function
> >>>> .init.text:ram_console_init()
> >>>> The function ram_console_driver_probe() references
> >>>> the function __init ram_console_init().
> >>>> This is often because ram_console_driver_probe lacks a __init
> >>>> annotation or the annotation of ram_console_init is wrong.
> >>>>
> >>>> Mark ram_console_driver_probe() as __devinit because it's a probe
> >>>> function and propagate the __devinit markings to the __init
> >>>> functions the probe calls.
> >>> What .config configuration causes this to happen? I don't see this here
> >>> in my builds, what am I doing wrong?
> >>>
> >> #
> >> # Android
> >> #
> >> CONFIG_ANDROID=y
> >> # CONFIG_ANDROID_BINDER_IPC is not set
> >> # CONFIG_ASHMEM is not set
> >> # CONFIG_ANDROID_LOGGER is not set
> >> CONFIG_ANDROID_RAM_CONSOLE=y
> >> # CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION is not set
> >> # CONFIG_ANDROID_TIMED_OUTPUT is not set
> >> # CONFIG_ANDROID_LOW_MEMORY_KILLER is not set
> >> # CONFIG_ANDROID_SWITCH is not set
> >> # CONFIG_PHONE is not set
> >>
> >>
> >> Perhaps you're missing this patch if you're on an ARM compiler?
> >>
> >> 6e2e340 (ARM: 7324/1: modpost: Fix section warnings for ARM for many
> >> compilers, 2012-02-14)
> > Nope, I'm building this on x86-64 which warns on this type of thing all
> > the time.
> >
> > My .config looks like this:
> >
> > #
> > # Android
> > #
> > CONFIG_ANDROID=y
> > CONFIG_ANDROID_BINDER_IPC=y
> > CONFIG_ASHMEM=y
> > CONFIG_ANDROID_LOGGER=m
> > CONFIG_ANDROID_PERSISTENT_RAM=y
> > CONFIG_ANDROID_RAM_CONSOLE=y
> > CONFIG_ANDROID_TIMED_OUTPUT=y
> > # CONFIG_ANDROID_TIMED_GPIO is not set
> > CONFIG_ANDROID_LOW_MEMORY_KILLER=y
> > CONFIG_ANDROID_SWITCH=m
> > CONFIG_ANDROID_SWITCH_GPIO=m
> > CONFIG_ANDROID_INTF_ALARM=y
> > CONFIG_ANDROID_INTF_ALARM_DEV=y
> > CONFIG_ANDROID_ALARM_OLDDRV_COMPAT=y
> >
> > And I can't duplicate this at all. Could the recent fixes that John
> > sent me be the reason? Or something else?
> >
>
> This patch is based on your staging-next branch at c5ee121 (staging:
> android: ram_console: drop verbose ram_console support, 2012-03-07). It
> applied that ARM patch on top because I'm compiling with ARM.
The ram_console just got reworked a bunch by the patches I applied a few
hours ago (and you had responded to that thread), so even if I wanted to
take your patch, I can't :)
Care to redo it if it is needed after the rework that just happened?
> It looks like aggressive inlining by the x86 compiler hides this from
> you. I see that if I mark ram_console_init() as noinline
>
> diff --git a/drivers/staging/android/ram_console.c b/drivers/staging/android/ram_console.c
> index 73215e2..c468fa2 100644
> --- a/drivers/staging/android/ram_console.c
> +++ b/drivers/staging/android/ram_console.c
> @@ -205,7 +205,7 @@ ram_console_save_old(struct ram_console_buffer *buffer, char *dest)
> &buffer->data[0], buffer->start);
> }
>
> -static int __init ram_console_init(struct ram_console_buffer *buffer,
> +static noinline int __init ram_console_init(struct ram_console_buffer *buffer,
> size_t buffer_size, char *old_buf)
> {
> #ifdef CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION
>
>
> then I see the section mismatch when compiling on x86. Otherwise I don't
> see anything. Is there a bug in the section mismatch detection with
> respect to compiler inlining?
Possibly, but probably not, if the code is inlined, then there is no
error happening, so there's nothing to detect, right?
thanks,
greg k-h
next prev parent reply other threads:[~2012-03-08 18:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 1:34 [PATCH 00/11] staging: Android updates (take 2) John Stultz
2012-03-08 1:34 ` [PATCH 01/11] android: ram_console: set CON_ANYTIME console flag John Stultz
2012-03-08 1:34 ` [PATCH 02/11] android: ram_console: move footer strings John Stultz
2012-03-08 1:34 ` [PATCH 03/11] android: ram_console: drop early buffer support John Stultz
2012-03-08 1:34 ` [PATCH 04/11] android: ram_console: drop verbose ram_console support John Stultz
2012-03-08 1:34 ` [PATCH 05/11] android: ram_console: split out persistent ram John Stultz
2012-03-08 2:42 ` Greg KH
2012-03-08 3:06 ` Colin Cross
2012-03-08 17:33 ` Greg KH
2012-03-08 18:24 ` Colin Cross
2012-03-08 18:39 ` Greg KH
2012-03-08 3:59 ` John Stultz
2012-03-08 17:33 ` Greg KH
2012-03-08 1:34 ` [PATCH 06/11] android: persistent_ram: refactor ecc support John Stultz
2012-03-08 1:34 ` [PATCH 07/11] android: persistent_ram: handle reserving and mapping memory John Stultz
2012-03-08 1:34 ` [PATCH 08/11] android: persistent_ram: make persistent_ram_write atomic John Stultz
2012-03-08 1:34 ` [PATCH 09/11] android: persistent_ram: add notrace to persistent_ram_write John Stultz
2012-03-08 1:34 ` [PATCH 10/11] android: staging: ram_console: fix crash in ram_console_late_init John Stultz
2012-03-08 1:34 ` [PATCH 11/11] android: ram_console: honor dmesg_restrict John Stultz
2012-03-08 2:42 ` [PATCH 00/11] staging: Android updates (take 2) Greg KH
2012-03-08 9:08 ` [PATCH] staging: ram_console: Fix section mismatches Stephen Boyd
2012-03-08 17:56 ` Greg KH
2012-03-08 18:12 ` Stephen Boyd
2012-03-08 18:23 ` Greg KH
2012-03-08 18:34 ` Stephen Boyd
2012-03-08 18:43 ` Greg KH [this message]
2012-03-08 19:33 ` Stephen Boyd
2012-03-08 19:41 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120308184320.GA29273@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.