14 Jan, 2011
1 commit
-
Commit 34aacb2920 ("procfs: Use generic_file_llseek in /proc/kcore") broke
seeking on /proc/kcore. This changes it back to use default_llseek in
order to restore the original behavior.The problem with generic_file_llseek is that it only allows seeks up to
inode->i_sb->s_maxbytes, which is 2GB-1 on procfs, where the memory file
offset values in the /proc/kcore PT_LOAD segments may exceed or start
beyond that offset value.A similar revert was made for /proc/vmcore.
Signed-off-by: Dave Anderson
Acked-by: Frederic Weisbecker
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 May, 2010
1 commit
-
Extend KCORE_TEXT to cover the pages between _text and _stext, to allow
examining some important page table pages.`readelf -a` output on x86_64 before and after patch:
Type Offset VirtAddr PhysAddr
before LOAD 0x00007fff8100c000 0xffffffff81009000 0x0000000000000000
after LOAD 0x00007fff81003000 0xffffffff81000000 0x0000000000000000The newly covered pages are:
0xffffffff81000000 etc.
0xffffffff81001000
0xffffffff81002000
0xffffffff81003000
0xffffffff81004000
0xffffffff81005000
0xffffffff81006000
0xffffffff81007000
0xffffffff81008000Before patch, /proc/kcore shows outdated contents for the above page
table pages, for example:(gdb) p level3_ident_pgt
$1 = {} 0xffffffff81002000
(gdb) p/x *((pud_t *)&level3_ident_pgt)@512
$2 = {{pud = 0x1006063}, {pud = 0x0} }while the real content is:
root@hp /home/wfg# hexdump -s 0x1002000 -n 4096 /dev/mem
1002000 6063 0100 0000 0000 8067 0000 0000 0000
1002010 0000 0000 0000 0000 0000 0000 0000 0000
*
1003000That is, on a x86_64 box with 2GB memory, we can see first-1GB / full-2GB
identity mapping before/after patch:(gdb) p/x *((pud_t *)&level3_ident_pgt)@512
before $1 = {{pud = 0x1006063}, {pud = 0x0} }
after $1 = {{pud = 0x1006063}, {pud = 0x8067}, {pud = 0x0} }Obviously the content before patch is wrong.
Signed-off-by: Wu Fengguang
Cc: Andi Kleen
Cc: KAMEZAWA Hiroyuki
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 May, 2010
1 commit
-
* 'bkl/procfs' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing:
sunrpc: Include missing smp_lock.h
procfs: Kill the bkl in ioctl
procfs: Push down the bkl from ioctl
procfs: Use generic_file_llseek in /proc/vmcore
procfs: Use generic_file_llseek in /proc/kmsg
procfs: Use generic_file_llseek in /proc/kcore
procfs: Kill BKL in llseek on proc base
09 Apr, 2010
1 commit
-
/proc/kcore has no llseek and then falls down to use default_llseek.
This is racy against read_kcore() that directly manipulates fpos
but it doesn't hold the bkl there so using it in llseek doesn't
protect anything.Let's use generic_file_llseek() instead.
Signed-off-by: Frederic Weisbecker
Acked-by: Arnd Bergmann
Cc: Thomas Gleixner
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: John Kacur
Cc: KAMEZAWA Hiroyuki
Cc: Al Viro
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
25 Mar, 2010
1 commit
-
"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
08 Oct, 2009
1 commit
-
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
23 Sep, 2009
11 commits
-
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 -
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 -
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 -
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 -
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/kcoreBecause 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 -
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 -
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 -
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 -
Presently, kclist_add() only eats start address and size as its arguments.
Considering to make kclist dynamically reconfigulable, it's necessary to
know which kclists are for System RAM and which are not.This patch add kclist types as
KCORE_RAM
KCORE_VMALLOC
KCORE_TEXT
KCORE_OTHERThis "type" is used in a patch following this for detecting KCORE_RAM.
Signed-off-by: KAMEZAWA Hiroyuki
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: WANG Cong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patchset is for /proc/kcore. With this,
- many per-arch hooks are removed.
- /proc/kcore will know really valid physical memory area.
- /proc/kcore will be aware of memory hotplug.
- /proc/kcore will be architecture independent i.e.
if an arch supports CONFIG_MMU, it can use /proc/kcore.
(if the arch uses usual memory layout.)This patch:
/proc/kcore uses its own list handling codes. It's better to use
generic list codes.No changes in logic. just clean up.
Signed-off-by: KAMEZAWA Hiroyuki
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: WANG Cong
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
In 9063c61fd5cbd ("x86, 64-bit: Clean up user address masking") Linus
fixed the wrong size of /proc/kcore problem.But its size still looks insane, since it never equals the size of
physical memory.Signed-off-by: WANG Cong
Cc: "Eric W. Biederman"
Cc: Tao Ma
Cc:
Acked-by: KAMEZAWA Hiroyuki
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Sep, 2009
1 commit
-
/proc/kcore has its own routine to access vmallc area. It can be replaced
with vread(). And by this, /proc/kcore can do safe access to vmalloc
area.Signed-off-by: KAMEZAWA Hiroyuki
Cc: WANG Cong
Cc: Mike Smith
Cc: Nick Piggin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Oct, 2008
1 commit
-
Signed-off-by: Alexey Dobriyan
26 Jul, 2008
1 commit
-
ELF_CORE_EFLAGS is already used by the binfmt_elf coredumper to set correct
arch specific ELF header flags on coredumps. Use it for kcore dumps as well.
At the moment, this affects the CRIS and the H8300 arch.Signed-off-by: Edgar E. Iglesias
Cc: Mikael Starvik
Cc: Yoshinori Sato
Cc: Ralf Baechle
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Feb, 2008
1 commit
-
Remove now unnecessary inclusions of {asm,linux}/a.out.h.
[akpm@linux-foundation.org: fix alpha build]
Signed-off-by: David Howells
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Feb, 2008
1 commit
-
Checking if an address is a vmalloc address is done in a couple of places.
Define a common version in mm.h and replace the other checks.Again the include structures suck. The definition of VMALLOC_START and
VMALLOC_END is not available in vmalloc.h since highmem.c cannot be included
there.Signed-off-by: Christoph Lameter
Cc: Nick Piggin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Dec, 2006
1 commit
-
- Define "CORE" string as CORE_STR in single common place.
- Include terminating zero in CORE_STR length calculation for elf_buflen.
- Use roundup(,4) to include alignment in elf_buflen calculation.[akpm@osdl.org: simplification suggested by Roland]
Signed-off-by: Magnus Damm
Cc: Daniel Jacobowitz
Cc: Roland McGrath
Cc: Jakub Jelinek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2006
1 commit
-
o As per ELF specifications, it looks like that elf note "namesz" field
contains the length of "name" including the size of null character. And
currently we are filling "namesz" without taking into the consideration
the null character size.o Kexec-tools performs this check deligently hence I ran into the issue
while trying to open /proc/kcore in kexec-tools for some info.Signed-off-by: Vivek Goyal
Cc: "Eric W. Biederman"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Sep, 2006
1 commit
-
Conversions from kmalloc+memset to kzalloc.
Signed-off-by: Panagiotis Issaris
Jffs2-bit-acked-by: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jul, 2006
1 commit
-
Address a potential 'larger than buffer size' memory access by
clear_user(). Without this patch, this call to clear_user() can attempt to
clear too many (tsz) bytes resulting in a wrong (-EFAULT) return code by
read_kcore().Signed-off-by: Adam B. Jerome
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jul, 2006
1 commit
-
Move the roundup() macro from binfmt_elf.c into linux/kernel.h as it's
generally useful.[akpm@osdl.org: nuke all the other implementations]
Signed-off-by: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Jul, 2006
1 commit
-
Signed-off-by: Jörn Engel
Signed-off-by: Adrian Bunk
29 Mar, 2006
1 commit
-
This is a conversion to make the various file_operations structs in fs/
const. Basically a regexp job, with a few manual fixupsThe goal is both to increase correctness (harder to accidentally write to
shared datastructures) and reducing the false sharing of cachelines with
things that get dirty in .data (while .rodata is nicely read only and thus
cache clean)Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Jan, 2006
1 commit
-
fs: Use where capable() is used.
Signed-off-by: Randy Dunlap
Acked-by: Tim Schmielau
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
