linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Make modules work in Linus' tree on ARM
@ 2003-08-14 12:08 Russell King
  2003-08-14 16:19 ` Linus Torvalds
  0 siblings, 1 reply; 17+ messages in thread
From: Russell King @ 2003-08-14 12:08 UTC (permalink / raw)
  To: Linus Torvalds, Linux Kernel List

This patch allows modules to work in Linus' tree for ARM, and is the one
thing which prevents Linus' tree from building for any ARM machine.

After reviewing the /proc/kcore and kclist issues, I've decided that I'm
no longer prepared to even _think_ about supporting /proc/kcore on ARM -
it just gets too ugly, and adds too much code to make it worth the effort,
the time or the energy to implement a solution to that problem.  This is
especially true since most people use kgdb or similar rather than
/proc/kcore anyway.  /proc/kcore is a "wouldn't it be nice" feature.

The reasons that I'm going with this solution rather than fixing
/proc/kcore is that:

- to add a kclist entry for each module would mean hacking the kclist
  structure into vm_struct's ->page pointer with disgusting hacks.
  I think we can all agree that this isn't the way to go.  The
  alternative is to create Yet Another Memory Allocator, and this
  isn't something I want to see in what is now an embedded architecture.

- we'd need to find some way to dynamically reserve the virtual mapped
  memory regions for the kernel direct mapped RAM.  Since ARM uses a
  generic memory initialisation implementation which handles contiguous
  and discontiguous memory, it doesn't lend itself well to the kclist
  approach, and I'm not about to add extra callbacks from init/main.c
  (so we have kmalloc available) just to support this.

If someone _else_ wants to put the effort into fixing ARM modules to work
nicely with /proc/kcore, be my guest - I'm just no longer interested in
this problem space.

Maybe in 2.7 a generic "reserve an area of memory in this region" 
function like __get_vm_area below is in order?

Therefore, I'm providing a patch which adds the necessary changes to the
core kernel code to make the current modules solution work for ARM.

Please merge.

--- orig/mm/vmalloc.c	Tue May 27 10:05:48 2003
+++ linux/mm/vmalloc.c	Tue May 27 10:14:45 2003
@@ -178,21 +178,11 @@
 	return err;
 }
 
-
-/**
- *	get_vm_area  -  reserve a contingous kernel virtual area
- *
- *	@size:		size of the area
- *	@flags:		%VM_IOREMAP for I/O mappings or VM_ALLOC
- *
- *	Search an area of @size in the kernel virtual mapping area,
- *	and reserved it for out purposes.  Returns the area descriptor
- *	on success or %NULL on failure.
- */
-struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
+				unsigned long start, unsigned long end)
 {
 	struct vm_struct **p, *tmp, *area;
-	unsigned long addr = VMALLOC_START;
+	unsigned long addr = start;
 
 	area = kmalloc(sizeof(*area), GFP_KERNEL);
 	if (unlikely(!area))
@@ -209,12 +199,14 @@
 
 	write_lock(&vmlist_lock);
 	for (p = &vmlist; (tmp = *p) ;p = &tmp->next) {
+		if ((unsigned long)tmp->addr < addr)
+			continue;
 		if ((size + addr) < addr)
 			goto out;
 		if (size + addr <= (unsigned long)tmp->addr)
 			goto found;
 		addr = tmp->size + (unsigned long)tmp->addr;
-		if (addr > VMALLOC_END-size)
+		if (addr > end - size)
 			goto out;
 	}
 
@@ -239,6 +231,21 @@
 }
 
 /**
+ *	get_vm_area  -  reserve a contingous kernel virtual area
+ *
+ *	@size:		size of the area
+ *	@flags:		%VM_IOREMAP for I/O mappings or VM_ALLOC
+ *
+ *	Search an area of @size in the kernel virtual mapping area,
+ *	and reserved it for out purposes.  Returns the area descriptor
+ *	on success or %NULL on failure.
+ */
+struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+{
+	return __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END);
+}
+
+/**
  *	remove_vm_area  -  find and remove a contingous kernel virtual area
  *
  *	@addr:		base address

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: [PATCH] Make modules work in Linus' tree on ARM
@ 2003-08-14 17:16 John Bradford
  0 siblings, 0 replies; 17+ messages in thread
From: John Bradford @ 2003-08-14 17:16 UTC (permalink / raw)
  To: rmk, torvalds; +Cc: linux-kernel

> > After reviewing the /proc/kcore and kclist issues, I've decided that I'm
> > no longer prepared to even _think_ about supporting /proc/kcore on ARM -
>
> I suspect we should just remove it altogether.
>
> Does anybody actually _use_ /proc/kcore? It was one of those "cool 
> feature" things, but I certainly haven't ever used it myself except for 
> testing, and it's historically often been broken after various kernel 
> infrastructure updates, and people haven't complained..
>
> Comments?

I've used it on a few rare occasions for last-ditch data recovery
before, E.G. an application crashed that had a text file held in RAM
that wasn't ever written to disk.  Poking through /proc/kcore could
allow it's recovery.

Probably not a sufficent reason to keep it :-).

John.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: [PATCH] Make modules work in Linus' tree on ARM
@ 2003-08-14 17:42 Luck, Tony
  0 siblings, 0 replies; 17+ messages in thread
From: Luck, Tony @ 2003-08-14 17:42 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

Linus Torvalds wrote:
> On Thu, 14 Aug 2003, Russell King wrote:
> 
>>After reviewing the /proc/kcore and kclist issues, I've decided that I'm
>>no longer prepared to even _think_ about supporting /proc/kcore on ARM -
> 
> 
> I suspect we should just remove it altogether.
> 
> Does anybody actually _use_ /proc/kcore? It was one of those "cool 
> feature" things, but I certainly haven't ever used it myself except for 
> testing, and it's historically often been broken after various kernel 
> infrastructure updates, and people haven't complained..

I only fixed it up because someone at SGI complained that
my ia64 kernel virtual space re-arrangements had broken it
(even more ... it had never been right for ia64).

Even now, it's still full of races (e.g. if you start gdb to
look at /proc/kcore, then load or unload modules).

Plus gdb doesn't really understand that kcore is a special
file, so it caches values (read "jiffies" twice and notice
that it doesn't change ... because gdb cached the read).

So don't mistake my recent activity fixing kcore for interest
in its continued existence.

-Tony Luck

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2003-09-17  9:23 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-14 12:08 [PATCH] Make modules work in Linus' tree on ARM Russell King
2003-08-14 16:19 ` Linus Torvalds
2003-08-14 16:32   ` Russell King
2003-09-17  9:23     ` Russell King
2003-08-14 16:47   ` Alan Cox
2003-08-14 16:55     ` John Levon
2003-08-14 17:06       ` Alan Cox
2003-08-14 17:19         ` Linus Torvalds
2003-08-14 17:14       ` Linus Torvalds
2003-08-14 17:30         ` John Levon
2003-08-14 19:18           ` [PATCH] Export pointer size in oprofilefs John Levon
2003-08-14 17:24       ` [PATCH] Make modules work in Linus' tree on ARM Russell King
2003-08-14 20:12     ` Eli Carter
2003-08-14 20:42       ` Russell King
2003-08-18 19:27   ` Daniel Jacobowitz
2003-08-14 17:16 John Bradford
2003-08-14 17:42 Luck, Tony

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).