From: Russell King <rmk@arm.linux.org.uk>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Roman Zippel <zippel@linux-m68k.org>,
Horst von Brand <brand@jupiter.cs.uni-dortmund.de>,
Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Restore module support.
Date: Fri, 7 Feb 2003 10:03:19 +0000 [thread overview]
Message-ID: <20030207100319.A23442@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030207045419.9A11B2C0F8@lists.samba.org>; from rusty@rustcorp.com.au on Fri, Feb 07, 2003 at 03:53:44PM +1100
On Fri, Feb 07, 2003 at 03:53:44PM +1100, Rusty Russell wrote:
> Yes. PPC and PPC64 have the same issues: currently this is done by
> (1) putting nothing in the .init sections (on PPC64), and (2) with
> stubs when jumping outside the module code.
>
> This gives the same effect as the previous userspace loader: for PPC64
> noone cares about discarding init stuff, so it's firmly on the TODO
> list. ARM's priorities are obviously different.
As I say, I have this solution working, but its suboptimal, and I'll
probably push this Linus-wards if I can't resolve (2) soon.
> > 2. fix vmalloc and /proc/kcore to be able to cope with a separate module
> > region located below PAGE_OFFSET. Currently, neither play well with
> > this option.
>
> x86_64 has this, as does sparc64: they do their own allocation. Does
> ARM require something special in this regard? I'd love to see what
> you've got...
There are two problems - one I mentioned during on LKML recently:
Message-ID: <20030131102013.A19646@flint.arm.linux.org.uk>
This seems simple to resolve. We just need to make get_vm_area() ignore
mappings for invalid areas:
--- orig/mm/vmalloc.c Tue Nov 5 12:51:41 2002
+++ linux/mm/vmalloc.c Fri Feb 7 09:48:42 2003
@@ -210,6 +210,8 @@
write_lock(&vmlist_lock);
for (p = &vmlist; (tmp = *p) ;p = &tmp->next) {
+ if (tmp->addr < addr)
+ continue;
if ((size + addr) < addr)
goto out;
if (size + addr <= (unsigned long)tmp->addr)
Since the vmlist is an ordered list, and we place the modules below
VMALLOC_START, this change ensures that we will completely ignore any
vmlist entries below the current minimum address (addr) we're looking
for.
/proc/kcore currently assumes that:
1. all vmlist mappings are above PAGE_OFFSET.
2. all vmlist mappings are within VMALLOC_START to VMALLOC_END
Looking at fs/proc/kcore.c this morning, I have a couple of ideas to
solve this problem. Patch will follow later today, hopefully without
any ifdefs.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2003-02-07 9:53 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-31 0:09 [PATCH] Module alias and device table support Rusty Russell
2003-01-31 6:23 ` Kai Germaschewski
2003-01-31 9:41 ` Horst von Brand
2003-01-31 15:42 ` Ingo Oeser
2003-01-31 22:33 ` Roman Zippel
2003-02-01 0:48 ` Kai Germaschewski
2003-02-01 1:22 ` Roman Zippel
2003-02-01 2:59 ` Kai Germaschewski
2003-02-01 10:31 ` Roman Zippel
2003-02-01 3:49 ` Rusty Russell
2003-02-01 7:20 ` Kai Germaschewski
2003-02-01 23:02 ` Horst von Brand
2003-02-03 0:52 ` Rusty Russell
2003-02-03 2:49 ` John Levon
2003-02-03 10:34 ` Rusty Russell
2003-02-04 9:56 ` Horst von Brand
2003-02-05 0:00 ` Rusty Russell
2003-02-03 8:31 ` Horst von Brand
2003-02-03 10:52 ` Rusty Russell
2003-02-04 8:05 ` Horst von Brand
2003-02-04 8:51 ` Rusty Russell
2003-02-06 23:09 ` [PATCH] Restore module support Roman Zippel
2003-02-06 23:25 ` Greg KH
2003-02-07 0:01 ` Roman Zippel
2003-02-07 4:06 ` Greg KH
2003-02-07 9:39 ` Roman Zippel
2003-02-07 18:01 ` Roman Zippel
2003-02-07 0:10 ` Russell King
2003-02-07 4:53 ` Rusty Russell
2003-02-07 10:03 ` Russell King [this message]
2003-02-07 6:12 ` Kai Germaschewski
2003-02-07 9:46 ` Roman Zippel
2003-02-04 14:49 ` [PATCH] Module alias and device table support Roman Zippel
2003-02-03 13:40 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2003-02-06 23:49 [PATCH] Restore module support Adam J. Richter
2003-02-07 8:26 Rusty Russell
2003-02-07 10:05 ` Russell King
2003-02-08 4:32 ` Rusty Russell
2003-02-07 18:43 Luck, Tony
2003-02-07 19:50 ` Russell King
2003-02-07 21:15 Luck, Tony
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=20030207100319.A23442@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=brand@jupiter.cs.uni-dortmund.de \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=zippel@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.