linux-stable.git/fs/proc/kcore.c, branch linux-2.6.33.y

kcore: fix test for end of list

2011-11-07T21:47:36+00:00

commit 4fd2c20d964a8fb9861045f1022475c9d200d684 upstream.

"m" is never NULL here.  We need a different test for the end of list
condition.

Signed-off-by: Dan Carpenter 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Leonardo Chiquitto 
Signed-off-by: Greg Kroah-Hartman

fs: includecheck fix: proc, kcore.c

2009-10-08T14:36:38+00:00

fix the following 'make includecheck' warning:

  fs/proc/kcore.c: linux/mm.h is included more than once.

Signed-off-by: Jaswinder Singh Rajput 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

/proc/kcore: update stat.st_size after memory hotplug

2009-09-23T14:39:42+00:00

After memory hotplug (or other events in future), kcore size can be
modified.

To update inode->i_size, we have to know inode/dentry but we can't get it
from inside /proc directly.  But considerinyg memory hotplug, kcore image
is updated only when it's opened.  Then, updating inode->i_size at open()
is enough.

Signed-off-by: KAMEZAWA Hiroyuki 
Acked-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

/proc/kcore: fix stat.st_size

2009-09-23T14:39:42+00:00

Presently the size of /proc/kcore which can be read by 'ls -l' is 0.  But
it's not the correct value.

On x86-64, ls -l shows
 ... root root 140737486266368 2009-09-17 10:29 /proc/kcore
Then, 7FFFFFFE02000. This comes from vmalloc area's size.
(*) This shows "core" size, not  memory size.

This patch shows the size by updating "size" field in struct
proc_dir_entry.  Later, lookup routine will create inode and fill
inode->i_size based on this value.  Then, this has a problem.

 - Once inode is cached, inode->i_size will never be updated.

Then, this patch is not memory-hotplug-aware.

To update inode->i_size, we have to know dentry or inode.
But there is no way to lookup them by inside kernel. Hmmm....
Next patch will try it.

Signed-off-by: KAMEZAWA Hiroyuki 
Acked-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: more fixes for init

2009-09-23T14:39:42+00:00

proc_kcore_init() doesn't check NULL case.  fix it and remove unnecessary
comments.

Signed-off-by: KAMEZAWA Hiroyuki 
Acked-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: register module area in generic way

2009-09-23T14:39:42+00:00

Some archs define MODULED_VADDR/MODULES_END which is not in VMALLOC area.
This is handled only in x86-64.  This patch make it more generic.  And we
can use vread/vwrite to access the area.  Fix it.

Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Jiri Slaby 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: register vmemmap range

2009-09-23T14:39:41+00:00

Benjamin Herrenschmidt  pointed out that vmemmap
range is not included in KCORE_RAM, KCORE_VMALLOC ....

This adds KCORE_VMEMMAP if SPARSEMEM_VMEMMAP is used.  By this, vmemmap
can be readable via /proc/kcore

Because it's not vmalloc area, vread/vwrite cannot be used.  But the range
is static against the memory layout, this patch handles vmemmap area by
the same scheme with physical memory.

This patch assumes SPARSEMEM_VMEMMAP range is not in VMALLOC range.  It's
correct now.

[akpm@linux-foundation.org: fix typo]
Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Jiri Slaby 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: WANG Cong 
Cc: Benjamin Herrenschmidt 
Cc: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: use registerd physmem information

2009-09-23T14:39:41+00:00

For /proc/kcore, each arch registers its memory range by kclist_add().
In usual,

	- range of physical memory
	- range of vmalloc area
	- text, etc...

are registered but "range of physical memory" has some troubles.  It
doesn't updated at memory hotplug and it tend to include unnecessary
memory holes.  Now, /proc/iomem (kernel/resource.c) includes required
physical memory range information and it's properly updated at memory
hotplug.  Then, it's good to avoid using its own code(duplicating
information) and to rebuild kclist for physical memory based on
/proc/iomem.

Signed-off-by: KAMEZAWA Hiroyuki 
Signed-off-by: Jiri Slaby 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: WANG Cong 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: register text area in generic way

2009-09-23T14:39:41+00:00

Some 64bit arch has special segment for mapping kernel text.  It should be
entried to /proc/kcore in addtion to direct-linear-map, vmalloc area.
This patch unifies KCORE_TEXT entry scattered under x86 and ia64.

I'm not familiar with other archs (mips has its own even after this patch)
but range of [_stext ..._end) is a valid area of text and it's not in
direct-map area, defining CONFIG_ARCH_PROC_KCORE_TEXT is only a necessary
thing to do.

Note: I left mips as it is now.

Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kcore: register vmalloc area in generic way

2009-09-23T14:39:41+00:00

For /proc/kcore, vmalloc areas are registered per arch.  But, all of them
registers same range of [VMALLOC_START...VMALLOC_END) This patch unifies
them.  By this.  archs which have no kclist_add() hooks can see vmalloc
area correctly.

Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds