From: Dmitry Torokhov <dtor@vmware.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux/m68k <linux-m68k@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: Early crash (was: Re: module: show version information for built-in modules in sysfs)
Date: Mon, 7 Feb 2011 00:19:33 -0800 [thread overview]
Message-ID: <20110207081933.GA11855@dtor-ws.eng.vmware.com> (raw)
In-Reply-To: <20110203002459.GA26729@dtor-ws.eng.vmware.com>
On Wed, Feb 02, 2011 at 04:24:59PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 02, 2011 at 04:10:04PM -0800, Andreas Schwab wrote:
> > Dmitry Torokhov <dtor@vmware.com> writes:
> >
> > > Even pointers? I'd expect pointers to be aligned on 4-bytes boundaries?
> >
> > Pointers are not special in any way. Why should they? On the machine
> > level pointers are just numbers.
>
> Are pointers (along with ints/longs) on m68k naturally aligned on word
> boundary even though they are 32 bit?
>
> Anyway, here is the description that introduced alignment statement:
>
> commit 02dba5c6439cff34936460b95cd1ba42b370f345
> Author: ak <ak>
> Date: Sat Jun 21 16:18:16 2003 +0000
>
> [PATCH] Fix over-alignment problem on x86-64
>
> Thanks to Jan Hubicka who suggested this fix.
>
> The problem seems to be that gcc generates a 32byte alignment for static
> objects > 32bytes. This causes gas to set a high alignment on the
> section, which causes the uneven (not multiple of sizeof(struct
> kernel_param)) section size. The pointer division with a base not being
> a multiple of sizeof(*ptr) then causes the invalid result.
>
> This just forces a small alignment, which makes the section end come out
> with the correct alignment.
>
> The only mystery left is why ld chose a 16 byte padding instead of
> 32byte.
>
> BKrev: 3ef485487jZN-h3PtASDeL2Vs55NIg
>
>
> I guess this does not directly apply to modversions since they are
> currently under 32 bytes, but I wonder what happen if we decide to
> extend one of the structures involved...
>
> I guess explicitly setting alignment requirement for struct
> module_version_attribute is the best option.
>
So here is the patch that explicitly specifies alignment for struct
module_version_attribute. I tested it on i386 and x86_64 and I believe
it will fix the issue with m68k but I do not have access to such a box.
Thanks,
Dmitry
From f0e0e10b58b22047e36e21a022abf5e86b5819c2 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dtor@vmware.com>
Date: Fri, 4 Feb 2011 13:30:10 -0800
Subject: [PATCH] module: explicitly align module_version_attribute structure
We force particular alignment when we generate attribute structures
when generation MODULE_VERSION() data and we need to make sure that
this alignment is followed when we iterate over these structures,
otherwise we may crash on platforms whose natural alignment is not
sizeof(void *), such as m68k.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
---
include/linux/module.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e7c6385..de5cd21 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -62,7 +62,7 @@ struct module_version_attribute {
struct module_attribute mattr;
const char *module_name;
const char *version;
-};
+} __attribute__ ((__aligned__(sizeof(void *))));
struct module_kobject
{
--
1.7.3.2
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dtor@vmware.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux/m68k <linux-m68k@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: Early crash (was: Re: module: show version information for built-in modules in sysfs)
Date: Mon, 7 Feb 2011 00:19:33 -0800 [thread overview]
Message-ID: <20110207081933.GA11855@dtor-ws.eng.vmware.com> (raw)
In-Reply-To: <20110203002459.GA26729@dtor-ws.eng.vmware.com>
On Wed, Feb 02, 2011 at 04:24:59PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 02, 2011 at 04:10:04PM -0800, Andreas Schwab wrote:
> > Dmitry Torokhov <dtor@vmware.com> writes:
> >
> > > Even pointers? I'd expect pointers to be aligned on 4-bytes boundaries?
> >
> > Pointers are not special in any way. Why should they? On the machine
> > level pointers are just numbers.
>
> Are pointers (along with ints/longs) on m68k naturally aligned on word
> boundary even though they are 32 bit?
>
> Anyway, here is the description that introduced alignment statement:
>
> commit 02dba5c6439cff34936460b95cd1ba42b370f345
> Author: ak <ak>
> Date: Sat Jun 21 16:18:16 2003 +0000
>
> [PATCH] Fix over-alignment problem on x86-64
>
> Thanks to Jan Hubicka who suggested this fix.
>
> The problem seems to be that gcc generates a 32byte alignment for static
> objects > 32bytes. This causes gas to set a high alignment on the
> section, which causes the uneven (not multiple of sizeof(struct
> kernel_param)) section size. The pointer division with a base not being
> a multiple of sizeof(*ptr) then causes the invalid result.
>
> This just forces a small alignment, which makes the section end come out
> with the correct alignment.
>
> The only mystery left is why ld chose a 16 byte padding instead of
> 32byte.
>
> BKrev: 3ef485487jZN-h3PtASDeL2Vs55NIg
>
>
> I guess this does not directly apply to modversions since they are
> currently under 32 bytes, but I wonder what happen if we decide to
> extend one of the structures involved...
>
> I guess explicitly setting alignment requirement for struct
> module_version_attribute is the best option.
>
So here is the patch that explicitly specifies alignment for struct
module_version_attribute. I tested it on i386 and x86_64 and I believe
it will fix the issue with m68k but I do not have access to such a box.
Thanks,
Dmitry
>From f0e0e10b58b22047e36e21a022abf5e86b5819c2 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dtor@vmware.com>
Date: Fri, 4 Feb 2011 13:30:10 -0800
Subject: [PATCH] module: explicitly align module_version_attribute structure
We force particular alignment when we generate attribute structures
when generation MODULE_VERSION() data and we need to make sure that
this alignment is followed when we iterate over these structures,
otherwise we may crash on platforms whose natural alignment is not
sizeof(void *), such as m68k.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
---
include/linux/module.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e7c6385..de5cd21 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -62,7 +62,7 @@ struct module_version_attribute {
struct module_attribute mattr;
const char *module_name;
const char *version;
-};
+} __attribute__ ((__aligned__(sizeof(void *))));
struct module_kobject
{
--
1.7.3.2
next prev parent reply other threads:[~2011-02-07 8:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 20:33 Early crash (was: Re: module: show version information for built-in modules in sysfs) Geert Uytterhoeven
2011-02-01 21:09 ` Dmitry Torokhov
2011-02-01 21:09 ` Dmitry Torokhov
2011-02-01 22:03 ` Geert Uytterhoeven
2011-02-01 22:26 ` Dmitry Torokhov
2011-02-02 14:48 ` Geert Uytterhoeven
2011-02-02 19:42 ` Dmitry Torokhov
2011-02-02 22:52 ` Andreas Schwab
2011-02-02 22:52 ` Andreas Schwab
2011-02-02 23:59 ` Dmitry Torokhov
2011-02-03 0:10 ` Andreas Schwab
2011-02-03 0:10 ` Andreas Schwab
2011-02-03 0:24 ` Dmitry Torokhov
2011-02-03 17:38 ` Andreas Schwab
2011-02-03 17:38 ` Andreas Schwab
2011-02-05 23:47 ` Thorsten Glaser
2011-02-08 21:31 ` Andreas Schwab
2011-02-08 22:46 ` Thorsten Glaser
2011-02-07 8:19 ` Dmitry Torokhov [this message]
2011-02-07 8:19 ` Dmitry Torokhov
2011-02-07 8:50 ` Early crash David Miller
2011-02-07 16:58 ` Dmitry Torokhov
2011-02-07 19:27 ` David Miller
2011-02-07 19:28 ` Dmitry Torokhov
2011-02-08 3:12 ` Rusty Russell
2011-02-08 3:31 ` David Miller
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=20110207081933.GA11855@dtor-ws.eng.vmware.com \
--to=dtor@vmware.com \
--cc=geert@linux-m68k.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=schwab@linux-m68k.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.