From: Rusty Russell <rusty@rustcorp.com.au>
To: Helge Deller <deller@gmx.de>
Cc: "linux-parisc" <linux-parisc@vger.kernel.org>,
Linux Kernel Development <linux-kernel@vger.kernel.org>,
Kyle McMartin <kyle@mcmartin.ca>,
Randolph Chung <randolph@tausq.org>,
Linus <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sam Ravnborg <sam@ravnborg.org>,
John David Anglin <dave@hiauly1.hia.nrc.ca>
Subject: Re: [PATCH] parisc: fix module loading failure of large kernel modules (take 2)
Date: Wed, 31 Dec 2008 09:15:40 +1030 [thread overview]
Message-ID: <200812310915.41693.rusty@rustcorp.com.au> (raw)
In-Reply-To: <4959346E.7060600@gmx.de>
On Tuesday 30 December 2008 07:04:54 Helge Deller wrote:
> This is the second take of the patch series.
> Changes to previous version:
> - new CONFIG_HAVE_MODULE_SECTION_STUBS config option
> - put stub entries of a code section in front of the section
>
> ____________
> The parisc port (esp. the 32bit kernel) currently lacks the ability to
> load large kernel modules like xfs or ipv6. This is a long outstanding
> bug and has already been reported a few times, e.g.:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350482,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508489
>
> The symptom is like this:
> # modprobe xfs
> FATAL: Error inserting xfs
> (/lib/modules/2.6.26-1-parisc/kernel/fs/xfs/xfs.ko): Invalid module
> format
>
> In dmesg:
> module xfs relocation of symbol xfs_btree_read_bufs is out of range
> (0x3ffefffe in 17 bits)
>
> The reason for the failure is, that the architecture only provides the
> R_PARISC_PCREL17F (for 32bit kernels) and R_PARISC_PCREL22F (for PA2.0
> and 64bit kernels) relocations, which sometimes can't reach the target
> address of the stub entry if the kernel module is too large. Currently
> parisc (like other architectures) creates one big PLT section for all
> stubs at the beginning of the init and core sections.
>
> The following two patches changes the parisc module loader to put stubs
> for the code sections in front of each section, so that the distance to
> the stubs more easily fits into the available 17/22 bits.
So now any one section has to pass 17 bits to break? How close are you with
the xfs module?
But it's kind of nasty, overloading sh_entsize further. Could we instead
do something like add a arch_module_section_size() weak fn which you can
overload? We'd use that in get_offset() so our layout and size calculations
were correct, and use sh_size everywhere else.
Cheers,
Rusty.
next prev parent reply other threads:[~2008-12-30 22:45 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-29 20:34 [PATCH] parisc: fix module loading failure of large kernel modules (take 2) Helge Deller
2008-12-29 20:34 ` Helge Deller
2008-12-29 20:43 ` [PATCH 1/2] module.c: fix module loading failure of large " Helge Deller
2008-12-29 20:43 ` Helge Deller
[not found] ` <20081230180724.GA15235@bombadil.infradead.org>
2008-12-30 18:10 ` Kyle McMartin
2008-12-30 18:18 ` Helge Deller
2008-12-30 19:42 ` [PATCH 1/2] module.c: fix module loading failure of large modules (take 3) Helge Deller
2008-12-29 20:45 ` [PATCH 2/2] parisc: fix module loading failure of large modules (take 2) Helge Deller
2008-12-29 20:45 ` Helge Deller
2008-12-30 19:55 ` [PATCH 2/2] parisc: fix module loading failure of large modules (take 3) Helge Deller
2008-12-30 19:55 ` Helge Deller
2008-12-30 22:45 ` Rusty Russell [this message]
2008-12-30 23:02 ` [PATCH] parisc: fix module loading failure of large kernel modules (take 2) Helge Deller
2008-12-31 4:08 ` Rusty Russell
2008-12-31 11:31 ` [PATCH] parisc: fix module loading failure of large kernel modules (take 4) Helge Deller
2008-12-31 11:36 ` [PATCH 2/2] parisc: fix module loading failure of large modules Helge Deller
2008-12-31 13:32 ` [PATCH] parisc: fix module loading failure of large kernel modules (take 4) Rusty Russell
2008-12-31 14:13 ` Helge Deller
2009-01-01 0:52 ` Rusty Russell
2009-01-01 12:02 ` Helge Deller
2008-12-31 17:29 ` Linus Torvalds
2008-12-31 17:36 ` Roland Dreier
2008-12-31 17:47 ` Linus Torvalds
2008-12-31 18:02 ` Linus Torvalds
2008-12-31 18:11 ` Sam Ravnborg
2009-01-02 11:31 ` Ingo Molnar
2008-12-31 18:54 ` Andrew Morton
2008-12-31 21:22 ` Linus Torvalds
2008-12-31 22:14 ` David Miller
2009-01-02 11:55 ` [PATCH] kbuild: Disallow GCC 4.1.0 / 4.1.1 Ingo Molnar
2009-01-02 13:43 ` Bartlomiej Zolnierkiewicz
2009-01-02 15:21 ` [PATCH] kbuild: Remove gcc 4.1.0 quirk from init/main.c Ingo Molnar
2009-01-02 15:21 ` Ingo Molnar
2009-01-02 18:05 ` Sam Ravnborg
2009-01-02 16:49 ` [PATCH] kbuild: Disallow GCC 4.1.0 / 4.1.1 Linus Torvalds
2009-01-02 17:38 ` Linus Torvalds
2009-01-02 17:46 ` Ingo Molnar
2009-01-02 17:54 ` [PATCH] Disallow gcc versions 3.{0,1} Ingo Molnar
2009-01-02 17:58 ` [PATCH] kbuild: Disallow GCC 4.1.0 / 4.1.1 Linus Torvalds
2009-01-02 18:01 ` Ingo Molnar
2009-01-02 18:05 ` Linus Torvalds
2009-01-02 18:08 ` Linus Torvalds
2009-01-02 19:54 ` Willy Tarreau
2009-01-02 20:18 ` Linus Torvalds
2009-01-02 17:57 ` Sam Ravnborg
2009-01-02 18:04 ` Linus Torvalds
2009-01-02 18:27 ` Sam Ravnborg
2009-01-02 18:28 ` Randy Dunlap
2009-01-02 18:51 ` Al Viro
2009-01-02 19:14 ` Andi Kleen
2009-01-02 22:52 ` Al Viro
2009-01-03 14:03 ` Krzysztof Halasa
2009-01-02 18:22 ` Ingo Molnar
2009-01-02 18:29 ` Sam Ravnborg
2009-01-02 18:33 ` Ingo Molnar
2009-01-02 19:05 ` Detlef Riekenberg
2009-01-02 22:27 ` Benjamin Herrenschmidt
2009-01-02 22:37 ` Sam Ravnborg
2009-01-02 17:44 ` Ingo Molnar
2009-01-01 14:24 ` [PATCH] parisc: fix module loading failure of large kernel modules (take 4) Ingo Molnar
2009-01-01 16:37 ` Andrew Morton
2008-12-31 17:39 ` Helge Deller
2008-12-31 18:24 ` James Bottomley
2008-12-31 22:16 ` Rusty Russell
2009-01-01 7:12 ` Jeremy Fitzhardinge
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=200812310915.41693.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=deller@gmx.de \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=randolph@tausq.org \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.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.