Thanks Thomas.
The failures appear to be similar to something corrupting the stack.
My initial impressions are it is somehow related to a change in the
kernel that allows parameters to be passed in registers versus on the
stack (i.e. REGPARM) but I can't find any evidence that I have this
configured/enabled. The access address it claims to fault on
(0x00000001) looks a lot like a register / variable content versus an
address. Given that my checks of parameters being passed
to the parent functions (i.e. kmalloc(), register_chrdev()) seem fine
and the error occurs deep within these functions, something/someone
must be either corrupting the memory pool base address or messing up
the stack.
The snippet from vmlinux:
static struct char_device_struct *
__register_chrdev_region(unsigned int major, unsigned int baseminor,
int minorct, const char *name)
{
c016d390: 55 push %ebp
c016d391: 57 push %edi
c016d392: 56 push %esi
c016d393: 53 push %ebx
c016d394: 83 ec 0c sub $0xc,%esp
c016d397: 89 c3 mov %eax,%ebx
c016d399: 89 54 24 08 mov %edx,0x8(%esp)
__you_cannot_kzalloc_that_much();
.
.
and onto the 0x61 offset
.
.
.
__asm__ __volatile__(
c016d3ee: 49 dec %ecx
c016d3ef: 78 08 js c016d3f9
<__register_chrdev_region+0x69>
-> c016d3f1: ac lods %ds:(%esi),%al
c016d3f2: aa stos %al,%es:(%edi)
c016d3f3: 84 c0 test %al,%al
c016d3f5: 75 f7 jne c016d3ee
<__register_chrdev_region+0x5e>
c016d3f7: f3 aa repz stos %al,%es:(%edi)
c016d3f9: b8 81 80 80 80 mov $0x80808081,%eax
c016d3fe: f7 eb imul %ebx
c016d400: 89 d8 mov %ebx,%eax
c016d402: c1 f8 1f sar $0x1f,%eax
c016d405: 8d 14 13 lea (%ebx,%edx,1),%edx
c016d408: c1 fa 07 sar $0x7,%edx
I've reinstalled the 'kmalloc()' call that also tripped:
BUG: unable to handle kernel NULL pointer dereference at virtual
address 00000025
printing eip:
c016659c
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: sys
CPU: 0
EIP: 0060:[<c016659c>] Not tainted VLI
EFLAGS: 00010246 (2.6.22.1 #1)
EIP is at kmem_flagcheck+0xc/0x20
eax: 00000001 ebx: 00000001 ecx: cf6aa000 edx: 10000000
esi: b7fc8e58 edi: 10000000 ebp: d001d065 esp: cf6aaf68
ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068
Process insmod (pid: 411, ti=cf6aa000 task=ce66b180 task.ti=cf6aa000)
Stack: c01671d9 b7fe688c d0018e80 b7fc8e58 b7fe688c cf6aaf9c d001d065
c123f940
000000d0 b7fe688c cf6aa000 c0129507 d0018e80 cf6aa000
c013e842 00000000
000058e2 b7ea4000 b7fc8e58 c0104192 b7ea4000 000058e2
0804a008 b7fc8e58
Call Trace:
[<c01671d9>] kmem_cache_alloc+0x29/0xa0
[<d001d065>] sysmon_init+0x65/0x270 [sys]
[<c0129507>] blocking_notifier_call_chain+0x17/0x20
[<c013e842>] sys_init_module+0xd2/0x140
[<c0104192>] syscall_call+0x7/0xb
=======================
Code: 18 e9 bb fe ff ff b9 f8 e3 45 c0 89 da b8 1f 27 3c c0 e8 38 ec
ff ff e9 6a ff ff ff 8d 76 00 f6 c2 01 74 07 f6 40 24 01 74 0b c3
<f6> 40 24 01 74 f9 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 83
EIP: [<c016659c>] kmem_flagcheck+0xc/0x20 SS:ESP 0068:cf6aaf68
static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags)
{
if (CONFIG_ZONE_DMA_FLAG) {
if (flags & GFP_DMA)
c0166590: f6 c2 01 test $0x1,%dl
c0166593: 74 07 je c016659c
<kmem_flagcheck+0xc>
BUG_ON(!(cachep->gfpflags & GFP_DMA));
c0166595: f6 40 24 01 testb $0x1,0x24(%eax)
c0166599: 74 0b je c01665a6
<kmem_flagcheck+0x16>
c016659b: c3 ret
else
BUG_ON(cachep->gfpflags & GFP_DMA);
-> c016659c: f6 40 24 01 testb $0x1,0x24(%eax)
c01665a0: 74 f9 je c016659b
<kmem_flagcheck+0xb>
c01665a2: 0f 0b ud2a
c01665a4: eb fe jmp c01665a4
<kmem_flagcheck+0x14>
c01665a6: 0f 0b ud2a
c01665a8: eb fe jmp c01665a8
<kmem_flagcheck+0x18>
c01665aa: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
c01665b0 <slab_get_obj>:
}
}
On Aug 2, 2007, at 1:43 PM, Thomas Petazzoni wrote:
Hi,
Le Wed, 1 Aug 2007 16:02:46 -0600,
Bruce Rowen <browen@xxxxxxxxxxxx> a écrit :
EFLAGS: 00010216 (2.6.22.1 #9)
EIP is at __register_chrdev_region+0x61/0x180
With a quick look at the code, I can't tell you what's wrong. To
understand what's happening, you can disassemble your vmlinux kernel
(available at the root directory of your kernel sources) using
'objdump
-S', and then look at the code of __register_chrdev_region around
offset 0x61.
If you need some help to understand the code, send to the list the
disassembled version of this function.
However, this failure doesn't look like as a memory allocation
failure:
the __register_chrdev_region() properly handles an allocation failure.
Sincerly,
Thomas
--
PETAZZONI Thomas - thomas.petazzoni@xxxxxxxx
http://{thomas,sos,kos}.enix.org - Jabber: thomas.petazzoni@xxxxxxxxx
http://{agenda,livret}dulibre.org - http://www.toulibre.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
