linux.git/fs/proc/generic.c, branch v2.6.28

proc: use WARN() rather than printk+backtrace

2008-10-23T09:34:38+00:00

Use WARN() rather than a printk() + backtrace();
this gives a more standard format message as well as complete
information (including line numbers etc) that will be collected
by kerneloops.org

Signed-off-by: Arjan van de Ven 
Signed-off-by: Alexey Dobriyan

proc: more debugging for "already registered" case

2008-09-13T21:41:50+00:00

Print parent directory name as well.

The aim is to catch non-creation of parent directory when proc_mkdir will
return NULL and all subsequent registrations go directly in /proc instead
of intended directory.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
[ Fixed insane printk string while at it.  - Linus ]
Signed-off-by: Linus Torvalds

[PATCH] proc: inode number fixlet

2008-08-25T05:18:03+00:00

Ouch, if number taken from IDA is too big, the intent was to signal an
error, not check for overflow and still do overflowing addition.

One still needs 2^28 proc entries to notice this.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Al Viro

[PATCH 2/2] proc: switch inode number allocation to IDA

2008-08-01T15:25:28+00:00

proc doesn't use "associate pointer with id" feature of IDR, so switch
to IDA.

NOTE, NOTE, NOTE:
	Do not apply if release_inode_number() still mantions MAX_ID_MASK!

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Al Viro

[PATCH 1/2] proc: fix inode number bogorithmetic

2008-08-01T15:25:27+00:00

Id which proc gets from IDR for inode number and id which proc removes
from IDR do not match. E.g. 0x11a transforms into 0x8000011a.

Which stayed unnoticed for a long time because, surprise, idr_remove()
masks out that high bit before doing anything.

All of this due to "| ~MAX_ID_MASK" in release_inode_number().

I still don't understand how it's supposed to work, because "| ~MASK"
is not an inversion for "& MAX" operation.

So, use just one nice, working addition. Make start offset unsigned int,
while I'm at it. It's longness is not used anywhere.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Al Viro

Use WARN() in fs/proc/

2008-07-26T19:00:08+00:00

Use WARN() instead of a printk+WARN_ON() pair; this way the message
becomes part of the warning section for better reporting/collection.
This way, the entire if() {} section can collapse into the WARN() as well.

Signed-off-by: Arjan van de Ven 
Acked-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: always do ->release

2008-07-25T17:53:44+00:00

Current two-stage scheme of removing PDE emphasizes one bug in proc:

		open
				rmmod
				remove_proc_entry
		close

->release won't be called because ->proc_fops were cleared.  In simple
cases it's small memory leak.

For every ->open, ->release has to be done.  List of openers is introduced
which is traversed at remove_proc_entry() if neeeded.

Discussions with Al long ago (sigh).

Signed-off-by: Alexey Dobriyan 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

netns: assign PDE->data before gluing entry into /proc tree

2008-05-02T11:12:41+00:00

In this unfortunate case, proc_mkdir_mode wrapper can't be used anymore and
this is no way to reuse proc_create_data due to nlinks assignment. So,
copy the code from proc_mkdir and assign PDE->data at the appropriate
moment.

Signed-off-by: Denis V. Lunev 
Signed-off-by: David S. Miller

proc: introduce proc_create_data to setup de->data

2008-04-29T15:06:20+00:00

This set of patches fixes an proc ->open'less usage due to ->proc_fops flip in
the most part of the kernel code.  The original OOPS is described in the
commit 2d3a4e3666325a9709cc8ea2e88151394e8f20fc:

    Typical PDE creation code looks like:

    	pde = create_proc_entry("foo", 0, NULL);
    	if (pde)
    		pde->proc_fops = &foo_proc_fops;

    Notice that PDE is first created, only then ->proc_fops is set up to
    final value. This is a problem because right after creation
    a) PDE is fully visible in /proc , and
    b) ->proc_fops are proc_file_operations which do not have ->open callback. So, it's
       possible to ->read without ->open (see one class of oopses below).

    The fix is new API called proc_create() which makes sure ->proc_fops are
    set up before gluing PDE to main tree. Typical new code looks like:

    	pde = proc_create("foo", 0, NULL, &foo_proc_fops);
    	if (!pde)
    		return -ENOMEM;

    Fix most networking users for a start.

    In the long run, create_proc_entry() for regular files will go.

In addition to this, proc_create_data is introduced to fix reading from
proc without PDE->data. The race is basically the same as above.

create_proc_entries is replaced in the entire kernel code as new method
is also simply better.

This patch:

The problem is the same as for de->proc_fops.  Right now PDE becomes visible
without data set.  So, the entry could be looked up without data.  This, in
most cases, will simply OOPS.

proc_create_data call is created to address this issue.  proc_create now
becomes a wrapper around it.

Signed-off-by: Denis V. Lunev 
Cc: "Eric W. Biederman" 
Cc: "J. Bruce Fields" 
Cc: Alessandro Zummo 
Cc: Alexey Dobriyan 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Bjorn Helgaas 
Cc: Chris Mason 
Acked-by: David Howells 
Cc: Dmitry Torokhov 
Cc: Geert Uytterhoeven 
Cc: Grant Grundler 
Cc: Greg Kroah-Hartman 
Cc: Haavard Skinnemoen 
Cc: Heiko Carstens 
Cc: Ingo Molnar 
Cc: James Bottomley 
Cc: Jaroslav Kysela 
Cc: Jeff Garzik 
Cc: Jeff Mahoney 
Cc: Jesper Nilsson 
Cc: Karsten Keil 
Cc: Kyle McMartin 
Cc: Len Brown 
Cc: Martin Schwidefsky 
Cc: Mathieu Desnoyers 
Cc: Matthew Wilcox 
Cc: Mauro Carvalho Chehab 
Cc: Mikael Starvik 
Cc: Nadia Derbey 
Cc: Neil Brown 
Cc: Paul Mackerras 
Cc: Peter Osterlund 
Cc: Pierre Peiffer 
Cc: Russell King 
Cc: Takashi Iwai 
Cc: Tony Luck 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: remove ->get_info infrastructure

2008-04-29T15:06:19+00:00

Now that last dozen or so users of ->get_info were removed, ditch it too.
Everyone sane shouldd have switched to seq_file interface long ago.

P.S.: Co-existing 3 interfaces (->get_info/->read_proc/->proc_fops) for proc
      is long-standing crap, BTW, thus
      a) put ->read_proc/->write_proc/read_proc_entry() users on death row,
      b) new such users should be rejected,
      c) everyone is encouraged to convert his favourite ->read_proc user or
         I'll do it, lazy bastards.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds