04 Jan, 2012
1 commit
-
both proc_dir_entry ->mode and populating functions
Signed-off-by: Al Viro
02 Nov, 2011
1 commit
-
Replace remaining direct i_nlink updates with a new set_nlink()
updater function.Signed-off-by: Miklos Szeredi
Tested-by: Toshiyuki Okajima
Signed-off-by: Christoph Hellwig
28 Jul, 2011
1 commit
-
Since __proc_create() appends the name it is given to the end of the PDE
structure that it allocates, there isn't a need to store a name pointer.
Instead we can just replace the name pointer with a terminal char array of
_unspecified_ length. The compiler will simply append the string to statically
defined variables of PDE type overlapping any hole at the end of the structure
and, unlike specifying an explicitly _zero_ length array, won't give a warning
if you try to statically initialise it with a string of more than zero length.Also, whilst we're at it:
(1) Move namelen to end just prior to name and reduce it to a single byte
(name shouldn't be longer than NAME_MAX).(2) Move pde_unload_lock two places further on so that if it's four bytes in
size on a 64-bit machine, it won't cause an unused hole in the PDE struct.Signed-off-by: David Howells
Signed-off-by: Alexey Dobriyan
Signed-off-by: Linus Torvalds
17 May, 2011
1 commit
-
* use proc_mkdir_mode() instead of create_proc_entry(S_IFDIR|...),
export proc_mkdir_mode() for that, oh well.
* don't supply S_IFREG to proc_create_data(), it's unnecessarySigned-off-by: Alexey Dobriyan
Signed-off-by: John W. Linville
24 Mar, 2011
1 commit
-
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
14 Jan, 2011
2 commits
-
For the common case where a proc entry is being removed and nobody is in
the process of using it, save a LOCK/UNLOCK pair.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
- ->low_ino is write-once field -- reading it under locks is unnecessary.
- /proc/$PID stuff never reaches pde_put()/free_proc_entry() --
PROC_DYNAMIC_FIRST check never triggers.- in proc_get_inode(), inode number always matches proc dir entry, so
save one parameter.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2011
2 commits
-
Reduce some branches and memory accesses in dcache lookup by adding dentry
flags to indicate common d_ops are set, rather than having to check them.
This saves a pointer memory access (dentry->d_op) in common path lookup
situations, and saves another pointer load and branch in cases where we
have d_op but not the particular operation.Patched with:
git grep -E '[.>]([[:space:]])*d_op([[:space:]])*=' | xargs sed -e 's/\([^\t ]*\)->d_op = \(.*\);/d_set_d_op(\1, \2);/' -e 's/\([^\t ]*\)\.d_op = \(.*\);/d_set_d_op(\&\1, \2);/' -i
Signed-off-by: Nick Piggin
-
Change d_delete from a dentry deletion notification to a dentry caching
advise, more like ->drop_inode. Require it to be constant and idempotent,
and not take d_lock. This is how all existing filesystems use the callback
anyway.This makes fine grained dentry locking of dput and dentry lru scanning
much simpler.Signed-off-by: Nick Piggin
10 Aug, 2010
1 commit
-
Replace inode_setattr with opencoded variants of it in all callers. This
moves the remaining call to vmtruncate into the filesystem methods where it
can be replaced with the proper truncate sequence.In a few cases it was obvious that we would never end up calling vmtruncate
so it was left out in the opencoded variant:spufs: explicitly checks for ATTR_SIZE earlier
btrfs,hugetlbfs,logfs,dlmfs: explicitly clears ATTR_SIZE earlier
ufs: contains an opencoded simple_seattr + truncate that sets the filesize just aboveIn addition to that ncpfs called inode_setattr with handcrafted iattrs,
which allowed to trim down the opencoded variant.Signed-off-by: Christoph Hellwig
Signed-off-by: Al Viro
28 May, 2010
1 commit
-
A quick test shows these comments are obsolete, so just remove them.
Signed-off-by: WANG Cong
Cc: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
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>
07 Mar, 2010
2 commits
-
* warn if creation goes on to non-existent directory
* warn if removal goes on from non-existing directory
* warn if non-existing proc entry is removedSigned-off-by: Alexey Dobriyan
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
remove_proc_entry() does
lock
lookup parent
unlock
lock
unlink proc entry from lists
unlockwhich can be made bit more correct by doing parent translation + unlink
without dropping lock.Signed-off-by: Alexey Dobriyan
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
04 Mar, 2010
1 commit
-
EXPORT_SYMBOL(proc_symlink);
EXPORT_SYMBOL(proc_mkdir);
EXPORT_SYMBOL(create_proc_entry);
EXPORT_SYMBOL(proc_create_data);
EXPORT_SYMBOL(remove_proc_entry);Those EXPORT_SYMBOL shouldn't be in fs/proc/root.c,
should be in fs/proc/generic.c.Signed-off-by: Helight.Xu
Signed-off-by: Al Viro
16 Dec, 2009
1 commit
-
* de_get() is trivial -- make inline, save a few bits of code, drop
"refcount is 0" check -- it should be done in some generic refcount
code, don't recall it's was helpful* rename GET and PUT functions to pde_get(), pde_put() for cool prefix!
* remove obvious and incorrent comments
* in remove_proc_entry() use pde_put(), when I fixed PDE refcounting to
be normal one, remove_proc_entry() was supposed to do "-1" and code now
reflects that.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Mar, 2009
2 commits
-
struct proc_dir_entry::owner is going to be removed. Now it's only necessary
to protect PDEs which are using ->read_proc, ->write_proc hooks.However, ->owner assignments are racy and make it very easy for someone to switch
->owner on live PDE (as some subsystems do) without fixing refcounts and so on.http://bugzilla.kernel.org/show_bug.cgi?id=12454
So, ->owner is on death row.
Proxy file operations exist already (proc_file_operations), just bump usecount
when necessary.Signed-off-by: Alexey Dobriyan
-
so that people will realize that it exists and can update it as needed.
Signed-off-by: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Alexey Dobriyan
28 Mar, 2009
1 commit
-
Signed-off-by: Al Viro
05 Jan, 2009
1 commit
-
There are four BKL users in proc: de_put(), proc_lookup_de(),
proc_readdir_de(), proc_root_readdir(),1) de_put()
-----------
de_put() is classic atomic_dec_and_test() refcount wrapper -- no BKL
needed. BKL doesn't matter to possible refcount leak as well.2) proc_lookup_de()
-------------------
Walking PDE list is protected by proc_subdir_lock(), proc_get_inode() is
potentially blocking, all callers of proc_lookup_de() eventually end up
from ->lookup hooks which is protected by directory's ->i_mutex -- BKL
doesn't protect anything.3) proc_readdir_de()
--------------------
"." and ".." part doesn't need BKL, walking PDE list is under
proc_subdir_lock, calling filldir callback is potentially blocking
because it writes to luserspace. All proc_readdir_de() callers
eventually come from ->readdir hook which is under directory's
->i_mutex -- BKL doesn't protect anything.4) proc_root_readdir_de()
-------------------------
proc_root_readdir_de is ->readdir hook, see (3).Since readdir hooks doesn't use BKL anymore, switch to
generic_file_llseek, since it also takes directory's i_mutex.Signed-off-by: Alexey Dobriyan
23 Oct, 2008
1 commit
-
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.orgSigned-off-by: Arjan van de Ven
Signed-off-by: Alexey Dobriyan
14 Sep, 2008
1 commit
-
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
25 Aug, 2008
1 commit
-
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
01 Aug, 2008
2 commits
-
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 -
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
27 Jul, 2008
1 commit
-
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
26 Jul, 2008
1 commit
-
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
02 May, 2008
1 commit
-
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
29 Apr, 2008
6 commits
-
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 -
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 -
proc-misc code is noticeably full of "if (de)" checks when PDE passed is
always valid. Remove them.Addition of such check in proc_lookup_de() is for failed lookup case.
Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
If valid "parent" is passed to proc_create/remove_proc_entry(), then name of
PDE should consist of only one path component, otherwise creation or or
removal will fail. However, if NULL is passed as parent then create/remove
accept full path as a argument. This is arbitrary restriction -- all
infrastructure is in place.So, patch allows the following to succeed:
create_proc_entry("foo/bar", 0, pde_baz);
remove_proc_entry("baz/foo/bar", &proc_root);Also makes the following to behave identically:
create_proc_entry("foo/bar", 0, NULL);
create_proc_entry("foo/bar", 0, &proc_root);Discrepancy noticed by Den Lunev (IIRC).
Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
proc_subdir_lock protects only modifying and walking through PDE lists, so
after we've found PDE to remove and actually removed it from lists, there is
no need to hold proc_subdir_lock for the rest of operation.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This usually saves one recompile to insert similar printk like below. :)
Sample nastygram:
remove_proc_entry: removing non-empty directory '/proc/foo', leaking at least 'bar'
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:776 remove_proc_entry+0x18a/0x200()
Modules linked in: foo(-) container fan battery dock sbs ac sbshc backlight ipv6 loop af_packet amd_rng sr_mod i2c_amd8111 i2c_amd756 cdrom i2c_core button thermal processor
Pid: 3034, comm: rmmod Tainted: G M 2.6.25-rc1 #5Call Trace:
[] warn_on_slowpath+0x64/0x90
[] printk+0x4e/0x60
[] remove_proc_entry+0x18a/0x200
[] mutex_lock_nested+0x1c8/0x2d0
[] __try_stop_module+0x0/0x40
[] sys_delete_module+0x14d/0x200
[] lockdep_sys_exit_thunk+0x35/0x67
[] __up_read+0x27/0xa0
[] trace_hardirqs_on_thunk+0x35/0x3a
[] system_call_after_swapgs+0x7b/0x80---[ end trace 10ef850597e89c54 ]---
Signed-off-by: Alexey Dobriyan
Cc: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Mar, 2008
1 commit
-
Current /proc/net is done with so called "shadows", but current
implementation is broken and has little chances to get fixed.The problem is that dentries subtree of /proc/net directory has
fancy revalidation rules to make processes living in different
net namespaces see different entries in /proc/net subtree, but
currently, tasks see in the /proc/net subdir the contents of any
other namespace, depending on who opened the file first.The proposed fix is to turn /proc/net into a symlink, which points
to /proc/self/net, which in turn shows what previously was in
/proc/net - the network-related info, from the net namespace the
appropriate task lives in.# ls -l /proc/net
lrwxrwxrwx 1 root root 8 Mar 5 15:17 /proc/net -> self/netIn other words - this behaves like /proc/mounts, but unlike
"mounts", "net" is not a file, but a directory.Changes from v2:
* Fixed discrepancy of /proc/net nlink count and selinux labeling
screwup pointed out by Stephen.To get the correct nlink count the ->getattr callback for /proc/net
is overridden to read one from the net->proc_net entry.To make selinux still work the net->proc_net entry is initialized
properly, i.e. with the "net" name and the proc_net parent.Selinux fixes are
Acked-by: Stephen SmalleyChanges from v1:
* Fixed a task_struct leak in get_proc_task_net, pointed out by Paul.Signed-off-by: Pavel Emelyanov
Acked-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
09 Feb, 2008
5 commits
-
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.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000024
printing eip: c1188c1b *pdpt = 000000002929e001 *pde = 0000000000000000
Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/block/sda/sda1/dev
Modules linked in: foo af_packet ipv6 cpufreq_ondemand loop serio_raw psmouse k8temp hwmon sr_mod cdromPid: 24679, comm: cat Not tainted (2.6.24-rc3-mm1 #2)
EIP: 0060:[] EFLAGS: 00210002 CPU: 0
EIP is at mutex_lock_nested+0x75/0x25d
EAX: 000006fe EBX: fffffffb ECX: 00001000 EDX: e9340570
ESI: 00000020 EDI: 00200246 EBP: e9340570 ESP: e8ea1ef8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cat (pid: 24679, ti=E8EA1000 task=E9340570 task.ti=E8EA1000)
Stack: 00000000 c106f7ce e8ee05b4 00000000 00000001 458003d0 f6fb6f20 fffffffb
00000000 c106f7aa 00001000 c106f7ce 08ae9000 f6db53f0 00000020 00200246
00000000 00000002 00000000 00200246 00200246 e8ee05a0 fffffffb e8ee0550
Call Trace:
[] seq_read+0x24/0x28a
[] seq_read+0x0/0x28a
[] seq_read+0x24/0x28a
[] seq_read+0x0/0x28a
[] proc_reg_read+0x60/0x73
[] proc_reg_read+0x0/0x73
[] vfs_read+0x6c/0x8b
[] sys_read+0x3c/0x63
[] sysenter_past_esp+0x5f/0xa5
[] destroy_inode+0x24/0x33
=======================
INFO: lockdep is turned off.
Code: 75 21 68 e1 1a 19 c1 68 87 00 00 00 68 b8 e8 1f c1 68 25 73 1f c1 e8 84 06 e9 ff e8 52 b8 e7 ff 83 c4 10 9c 5f fa e8 28 89 ea ff fe 4e 04 79 0a f3 90 80 7e 04 00 7e f8 eb f0 39 76 34 74 33
EIP: [] mutex_lock_nested+0x75/0x25d SS:ESP 0068:e8ea1ef8[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Alexey Dobriyan
Cc: "Eric W. Biederman"
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Print a warning if PDE is registered with a name which already exists in
target directory.Bug report and a simple fix can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=8798[\n fixlet and no undescriptive variable usage --adobriyan]
[akpm@linux-foundation.org: make printk comprehensible]
Signed-off-by: Zhang Rui
Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
proc symlinks always have valid ->data containing destination of symlink. No
need to check it on removal -- proc_symlink() already done it.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Move code around so as to reduce the number of forward-declarations.
Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Pseudo-code for lookup effectively is:
LOCK kernel
LOCK proc_subdir_lock
find PDE
UNLOCK proc_subdir_lockget inode
LOCK proc_subdir_lock
goto unlock
UNLOCK proc_subdir_lock
UNLOCK kernelWe can get rid of LOCK/UNLOCK pair after getting inode simply by jumping
to unlock_kernel() directly.Signed-off-by: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
