linux-stable.git/include/linux/proc_fs.h, branch linux-2.6.39.y

procfs: add stub for proc_mkdir_mode()

2011-05-18T09:55:24+00:00

Provide a stub for proc_mkdir_mode() when CONFIG_PROC_FS is not
enabled, just like the stub for proc_mkdir().

Fixes this linux-next build error:

  drivers/net/wireless/airo.c:4504: error: implicit declaration of function 'proc_mkdir_mode'

Signed-off-by: Randy Dunlap 
Cc: Stephen Rothwell 
Cc: Alexey Dobriyan 
Cc: "John W. Linville" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: make struct proc_dir_entry::namelen unsigned int

2011-03-24T02:46:37+00:00

1. namelen is declared "unsigned short" which hints for "maybe space savings".
   Indeed in 2.4 struct proc_dir_entry looked like:

        struct proc_dir_entry {
                unsigned short low_ino;
                unsigned short namelen;

   Now, low_ino is "unsigned int", all savings were gone for a long time.
   "struct proc_dir_entry" is not that countless to worry about it's size,
   anyway.

2. converting from unsigned short to int/unsigned int can only create
   problems, we better play it safe.

Space is not really conserved, because of natural alignment for the next
field.  sizeof(struct proc_dir_entry) remains the same.

Signed-off-by: Alexey Dobriyan 
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: add kclist types

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

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_OTHER

This "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

kcore: use usual list for kclist

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

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

Move junk from proc_fs.h to fs/proc/internal.h

2009-06-12T01:36:01+00:00

Signed-off-by: Al Viro

proc 2/2: remove struct proc_dir_entry::owner

2009-03-30T21:14:44+00:00

Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454

Signed-off-by: Alexey Dobriyan

proc: remove fs/proc/proc_misc.c

2008-10-23T14:54:05+00:00

Now that everything was moved to their more or less expected places,
apply rm(1).

Signed-off-by: Alexey Dobriyan

proc: move all /proc/kcore stuff to fs/proc/kcore.c

2008-10-23T14:32:38+00:00

Signed-off-by: Alexey Dobriyan

powerpc: Remove remains of /proc/ppc_htab

2008-10-07T03:26:19+00:00

commit 14cf11af6cf608eb8c23e989ddb17a715ddce109 ("powerpc: Merge enough to
start building in arch/powerpc.") unwired /proc/ppc_htab, and commit
917f0af9e5a9ceecf9e72537fabb501254ba321d ("powerpc: Remove arch/ppc and
include/asm-ppc") removed the rest of the /proc/ppc_htab support, but there are
still a few references left. Kill them for good.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Benjamin Herrenschmidt