"A month of sundays ago Mike Galbraith wrote:"
> On Fri, 18 Feb 2000, Peter T. Breuer wrote:
>
> A module containing only data is remarkably similar to a file.. and
> load/use/eject is DAMNED similar to open/read/close. I suppose cool
> ideas deserve to be reinvented once in a while :)
Maybe I commented on this to you already. It'll work. The sound drivers
do it. But it's "inconvenient". That's why I'm trying to avoid it.
> > I tried this. No bananas. Maybe I didn't do it right. To check that
> > theer's no obvious coding mistake, I just put the code of the second
> > module back into the first module, and it works fine again. It oopsed
> > after a short while the way I tried it with two modules.
Can one access an array allocated in one module from a second module?
(Linux modutils) 2.1.121 .
It still oopses. No change except moving the "run once" data and code
into the second module. Works fine when all in the same module. I'll
just put up a bit of the printout and the code section involved in case
people can see the memory management problem.
Kernel was in the second module, happily traversing a home array provided by
the first module, and looking up the keys it found in an away table in the
second module. When it found the key, it wrote the associated data value
back into another array provided from the first module.
All goes fine for the first 295 (out of 370) elements in the home array,
then bang! The keys are 4 byte longs. The data values are 4byte string
pointers (i.e. char*). It's vaguely possible that at that point the
total _data_ values returned just passed a 4K boundary.
It actually failed looking up key #296 in the home array. That would
be at an offset of 296*4 = 1184 bytes from the start.
Weird.
found key 293: 2694650647 at 1414
looking at key 294: 817350483
found key 294: 817350483 at 1415
looking at key 295: 2384547589
found key 295: 2384547589 at 1416
Unable to handle kernel paging request at virtual address c40bb000
current->tss.cr3 = 01b2a000, %cr3 = 01b2a000
*pde = 03d4d063
*pte = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c40bc0fb>]
EFLAGS: 00010282
eax: 00000025 ebx: c40bd6da ecx: c40bb000 edx: c3d08000
esi: 00000127 edi: 8e214f05 ebp: c1b29f3c esp: c1b29f04
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 193, process nr: 35, stackpage=c1b29000)
Stack: 8e214f05 00000588 c40bc000 00000001 c40ba000 00000246 c40bc000 c40bc000
c40bb000 00000206 c40bc000 00000001 00000e32 c40c8d9c c40c8d9c c011590f
c1b28000 0804f6e0 c40bc000 bffff284 00000000 c40c8d9c c1b29f78 c1b29f70
Call Trace: [<c40bc000>] [<c40ba000>] [<c40bc000>]
[<c40bc000>] [<c40bb000>] [<c40bc000>] [<c40c8d9c>]
[<c40c8d9c>] [<c011590f>] [<c40bc000>] [<c40c8d9c>]
[<c40ba000>] [<c40bc048>] [<c01090cc>] [<c40bc000>]
Code: 89 19 83 c4 10 eb 1a 89 f6 57 56 68 26 1b 0c c4 e8 9c 74 05
Dump of assembler code for function foo: (I think!)
0x0 <foo>: movl %ebx,(%ecx)
0x2 <foo+2>: addl $0x10,%esp
0x5 <foo+5>: jmp 0x21 <foo+33>
0x7 <foo+7>: movl %esi,%esi
0x9 <foo+9>: pushl %edi
0xa <foo+10>: pushl %esi
0xb <foo+11>: pushl $0xc40c1b26
0x10 <foo+16>: Cannot access memory at address 0x11.
for (count = 0; count < ucLen; count++) { // ucLen is 370
int i;
Key key = ucKey[count]; // first module's array
printk (KERN_INFO "looking at key %d: %u\n", count, key);
for (i = 0; i < ucAll; i++) { // ucAll is ~ 4000
if (key == ucIndexKey[i]) // second module's table
break;
}
if (i < ucAll) {
printk (KERN_INFO "found key %d: %u at %d\n", count, key, i);
ucName[count] = ucIndexName[i]; // write to first from second
} else {
printk (KERN_INFO "lost key %d: %u\n", count, key);
ucName[count] = "????";
}
}
Mmm ... making some minor changes in the memory allocation strategy
(making real sure that all arrays are allocated from kmalloc) doesn't change
the result, just the place at which the bang happens:
...
looking at key 271: 349962338
found key 271: 349962338 at 1249
Unable to handle kernel paging request at virtual address c40bb000
current->tss.cr3 = 01b21000, %cr3 = 01b21000
*pde = 03d4d063
*pte = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c40bc0fb>]
EFLAGS: 00010282
eax: 00000024 ebx: c40bdf3f ecx: c40bb000 edx: c3d08000
esi: 0000010f edi: 14dc0062 ebp: c1b23f3c esp: c1b23f04
ds: 0018 es: 0018 ss: 0018
Process insmod (pid: 211, process nr: 36, stackpage=c1b23000)
Stack: 14dc0062 000004e1 c40bc000 00000001 c40ba000 00000246 c40bc000 c40bc000
c40bb000 00000203 c40bc000 00000001 00000e32 c40c8d9c c40c8d9c c011590f
c1b22000 0804f6e0 c40bc000 bffff284 00000000 c40c8d9c c1b23f78 c1b23f70
Call Trace: [<c40bc000>] [<c40ba000>] [<c40bc000>] [<c40bc000>] [<c40bb000>] [<c40bc000>] [<c40c8d9c>]
[<c40c8d9c>] [<c011590f>] [<c40bc000>] [<c40c8d9c>] [<c40ba000>] [<c40bc048>] [<c01090cc>] [<c40bc000>]
Code: 89 19 83 c4 10 eb 1a 89 f6 57 56 68 26 1b 0c c4 e8 9c 74 05
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:24 EST