[lkml]   [2000]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Hi all,

A friend of mine just told me he could rm /proc/net/arp. Although I thought
he really needed to sleep, I tried it myself and was surprized to discover that
it was possible to change directory permissions in nearly all /proc subdirs,
but also remove many entries in /proc. There are two problems with this :

- I've found no way to make these entries appear again. Unmounting and
remounting has no effect.
- removing certain entries (or certain amount of entries) causes some
oopses (log attached).

This has been verified on kernel 2.2.14 and 2.2.17pre19. A quick turn-around would
be to remount /proc read-only after having set what you need in /proc/sys, but
that may hurt several configs.

I don't even understand why there's a "remove_proc_entry" function. Since the /proc
seems to stay coherent during a kernel's uptime, I suspect that nobody uses it
(except for rm -rf /proc/net/*, of course). Wouldn't it be better to simply replace
it with NULL in fs/proc/root.c ? I will quickly test this, but don't know what can
be the implications for now.

Hopefully it's not too late to fix it before final 2.2.17. Not tested it on 2.4 yet.

I'll recompile one kernel and post an obvious patch to remove remove_proc_entry()
soon if that seems to work. Anyway, it will still be possible to change the permissions
in the subdirectories. Perhaps this is desired behaviour ...



[shortened oops trace]

remove_proc_entry: net/raw busy, count=1
de_put: deferred delete of raw
proc_file_unlink: deleting ip_masq/app
remove_proc_entry: ip_masq/app busy, count=1
de_put: deferred delete of app
proc_file_unlink: deleting ip_masq/mfw
remove_proc_entry: ip_masq/mfw busy, count=1
de_put: deferred delete of mfw
kfree: Bad obj c027b280
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 03c6d000, %cr3 = 03c6d000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0121d6a>]
EFLAGS: 00010296
eax: 0000001b ebx: c027b280 ecx: 00000005 edx: 00000001
esi: c027b280 edi: c2dbac20 ebp: c380a000 esp: c3c35e0c
ds: 0018 es: 0018 ss: 0018
Process rm (pid: 254, process nr: 9, stackpage=c3c35000)
Stack: c029ad43 c029ad62 c027b280 c2d47ba0 c2dbac20 c380a000 00000000 c029ad62
c029ad43 c0114851 c027dcc0 c029ad62 c029ad62 c015047d c027b280 c2d47ba0
c2dbac20 c380a000 00000292 00000001 c029ad62 c014f1ff c027b280 c00bdc80
Call Trace: [<c0114851>] [<c015047d>] [<c014f1ff>] [<c014f1f6>] [<c0231ea0>] [<c0240444>] [<c01e6c9f>]
[<c014f249>] [<c0114851>] [<c0114889>] [<c0132fcf>] [<c0150543>] [<c02320e0>] [<c0240444>] [<c0132001>]
[<c014ffdd>] [<c014fff2>] [<c012d11d>] [<c012db1e>] [<c012f2dc>] [<c012dba5>] [<c012dbdb>] [<c010a0d2>]
Code: c7 05 00 00 00 00 00 00 00 00 83 c4 10 5b 5e 5f 5d 83 c4 1c

>>EIP: c0121d6a <kfree+192/1a8>
Trace: c0114851 <printk+121/168>
Trace: c015047d <free_proc_entry+21/28>
Trace: c014f1ff <de_put+57/60>
Trace: c014f1f6 <de_put+4e/60>
Trace: c0231ea0 <cprt+38c0/e700>
Trace: c0240444 <timer_bug_msg+1424/b500>
Trace: c01e6c9f <set_cursor+77/90>
Trace: c014f249 <proc_delete_inode+2d/38>
Trace: c014ffdd <proc_unlink+35/58>
Trace: c010a0f4 <system_call+34/40>
Code: c0121d6a <kfree+192/1a8> 00000000 <_EIP>: <===
Code: c0121d6a <kfree+192/1a8> 0: c7 05 00 00 00 00 00 movl $0x0,0x0 <===
Code: c0121d71 <kfree+199/1a8> 7: 00 00 00
Code: c0121d74 <kfree+19c/1a8> a: 83 c4 10 add $0x10,%esp
Code: c0121d77 <kfree+19f/1a8> d: 5b pop %ebx
Code: c0121d78 <kfree+1a0/1a8> e: 5e pop %esi
Code: c0121d79 <kfree+1a1/1a8> f: 5f pop %edi
Code: c0121d7a <kfree+1a2/1a8> 10: 5d pop %ebp
Code: c0121d7b <kfree+1a3/1a8> 11: 83 c4 1c add $0x1c,%esp

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.049 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site