> 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)