Messages in this thread |  | | | Date | Sat, 3 Jan 1998 16:11:03 -0500 (EST) | | From | James Mastros <> | | Subject | Re: PROPOSAL: /proc/dev |
| |
On 2 Jan 1998, Linus Torvalds wrote:
> In article <Pine.LNX.3.96.980101162816.6131B-100000@jennifer-unix.dyn.ml.org>, > James Mastros <root@jennifer-unix.dyn.ml.org> wrote: > >On Thu, 1 Jan 1998, Linus Torvalds wrote: > >> > >> Finally, I think it would be good to try to use the dcache to actually > >> remember the names of the files rather than having a separate data > >> structure for names. > >Wow... two one one issue... Thanks for the code... (Export > >"/usr/src/linux/memfs/names.c" Quit Yes "cd /usr/src/linux/memfs/" "jed > >names.c" <remove english>). > > Careful. That "code" was typed in while writing the email, and it was > never compiled nor even really thought about very hard. It _should_ be > fairly close to working, but there might be bad thinko's there. One I > know of is the readdir() thing - it assumes that the linked list is > untouched while it copies the names with "filldir()", so it should > really be protected with a semaphore against adding or deleting entries > etc etc. I noticed some of them: the if that turned into a do first <G>... I forgot all about locking though... (whatever: not nearly ready for that part: I need to get it to not mount (IE return error) without oopsing (and making all later [u]mounts hang)!)
> >> Too bad we didn't have the dcache when the original > >> /proc was done, but these days you could actually populate /proc with the > >> generic dcache functions. > >But the problem there is that then we need an inode for every file (don't > >we?), and inodes are big structures (which it probably shouldn't be, but > >that is a topic for another day). > [...] > Btw, devfs should probably think long and hard about pty's... Yeha. I think I'm going to have the same code as loads modules create VTs... master/slave pairs I'm not too sure about, but can probably be done similarly.
> Linus -=- James Mastros
Now, about that oops (those oopsen, technicly):
Unable to handle kernel NULL pointer dereference at virtual address 00000000 current->tss.cr3 = 015d2000, %cr3 = 015d2000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c012f57e>] EFLAGS: 00010292 eax: 00000000 ebx: c0507c64 ecx: 00000000 edx: c0507ccc esi: 00000001 edi: c01c8628 ebp: c01d4630 esp: c14cfeac ds: 0018 es: 0018 ss: 0018 Process mount (pid: 1117, process nr: 26, stackpage=c14cf000) Stack: c0507c64 c01c8628 00000001 c01d4630 c1540002 c012f644 c01d4630 00000001 c01c8628 c01d4630 00000002 c2809268 c01c54a6 c28090a0 c01d4630 00000001 c01d4630 c012765e c01d4630 00000000 00000000 ffffffea 00000000 00000002 Call Trace: [<c012f644>] [<c2809268>] [<c28090a0>] [<c012765e>] [<c0127a60>] [<c280925d>] [<c280925d>] [<c0127fba>] [<c280925d>] [<c0109988>] Code: 8b 00 ff d0 83 c4 04 83 63 70 fd 8d 43 58 e8 eb 12 fe ff 89 Using symbols.more' to map addresses to symbols.
>>EIP: c012f57e <get_new_inode+8a/108> Trace: c012f644 <get+48/80> Trace: c2809268 Trace: c28090a0 Trace: c012765e <read_super+b2/d8> Trace: c0127a60 <do_mount+c8/144> Trace: c280925d Trace: c280925d Trace: c0127fba <sys_mount+29e/300> Trace: c280925d Trace: c0109988 <system_call+38/40> Code: c012f57e <get_new_inode+8a/108> movl (%eax),%eax Code: c012f580 <get_new_inode+8c/108> call *%eax Code: c012f582 <get_new_inode+8e/108> addl $0x4,%esp Code: c012f585 <get_new_inode+91/108> andl $0xfffffffd,0x70(%ebx) Code: c012f589 <get_new_inode+95/108> leal 0x58(%ebx),%eax Code: c012f58c <get_new_inode+98/108> call fffe12fe <_EIP+fffe12fe> Code: c012f591 <get_new_inode+9d/108> movl %eax,(%eax) Code: c012f593 <get_new_inode+9f/108> nop Code: c012f594 <get_new_inode+a0/108> nop Code: c012f595 <get_new_inode+a1/108> nop (memfs.o's memfs_read_super is at c2809048)
Now, I know that the null pointer that is being dereferenced is eax = sb->s_op in the superblock that memfs_read_super is passed (I changed it to 0xdeadbeef, and got that 0xdeadbeef couuldn't be paged in). Unfornatly, I return NULL in that function, so why is sb->s_op being referenced? And, more importantly (perhaps), why is it _called_? It isn't a function!
Also, why does the call-stack show multiple calls inside of memfs_read_super?
Code for memfs avaible at upon request (219226 bytes, .tgz). (Note: you need to make some trivial changes to fs/Makefile and fs/Configure.in to get it to compile). All this is under 2.1.76 (haven't gotten 2.1.77 yet).
(BTW - how is it that ppl translase oopsen to c code? I've seen it on this list before, but never figured out how to do it...)
-=- James Mastros -- Information as a base of power is coming to an end. In the way the world works tomorrow, the power to *do* *something* *with* *information* is what will matter.
-=- James Mastros, rephrasing Nugget (David McNett, distributed.net Big Man)
|  |