Skip to contentSkip to conversation

filp_open() in 2.2.19 causes memory corruption

DISCUSSION Manfred Spraul 3 participants 4 messages Apr 23, 2001

lore
Share & tools
lore

Manfred Spraul

author
#0 lore raw

Are you sure the trace is decoded correctly?

Quoted 5 lines
CPU:    0 
EIP:    0010:[sys_mremap+31/884] 
EFLAGS: 00010206
Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9

ac ae is
lodsb
scasb

Could you run
#objdump --disassemble-all --reloc linux/mm/mremap.o | less

and check that the code is really at offset 31 of sys_mremap?

And is it correct that only 64 MB memory is installed/enabled?

--
Manfred

#1 lore raw
Quoted 14 lines · Manfred Spraul

Are you sure the trace is decoded correctly?

Quoted 5 lines
CPU:    0 
EIP:    0010:[sys_mremap+31/884] 
EFLAGS: 00010206
Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9

ac ae is
lodsb
scasb

Could you run
#objdump --disassemble-all --reloc linux/mm/mremap.o | less

Quoted 6 lines

and check that the code is really at offset 31 of sys_mremap?

And is it correct that only 64 MB memory is installed/enabled?

--
Manfred

Manfred,

This is what's being reported when I produce the oops. I think we have memory corruption somewhere, which explains the funky code offsets. It's easy to reproduce. Call filp_open with the handle table I gave you on a single IDE system with **NO** tape drive in the system, and it crashes quite after the module is loaded the fisrt time, then unloaded, and reloaded a second time. The oops happens on the second insmod of the module. I can provide you the actual module itself built with all the code if you want to reproduce it.

It's 100% reproduceable.

Jeff

Quoted 1 line
#2 lore raw
In reply to Manfred Spraul
Quoted 4 lines · [email protected] said:

Are you sure the trace is decoded correctly?

Quoted 2 lines
CPU:    0 
EIP:    0010:[sys_mremap+31/884]

Probably not. It looks like it was munged by klogd. Some distributions are still shipping with klogd configured to destroy the original information on the way to the log, without even making it do a sanity check that the System.map it's using actually matches the current kernel.

Jeff, please disable the broken klogd symbol munging and reproduce it, running the oops through ksymoops manually. Ksymoops should have built-in sanity checks on the System.map it tries to use.

Also, please make sure you report this as a serious bug with the vendor of whatever distribution you're running on this box.

--
dwmw2

#3 lore raw
In reply to Manfred Spraul
Quoted 12 lines · David Woodhouse
Quoted 4 lines · [email protected] said:

Are you sure the trace is decoded correctly?

Quoted 2 lines
CPU:    0 
EIP:    0010:[sys_mremap+31/884]

Probably not. It looks like it was munged by klogd. Some distributions are still shipping with klogd configured to destroy the original information on the way to the log, without even making it do a sanity check that the System.map it's using actually matches the current kernel.

Quoted 7 lines

Jeff, please disable the broken klogd symbol munging and reproduce it, running the oops through ksymoops manually. Ksymoops should have built-in sanity checks on the System.map it tries to use.

Also, please make sure you report this as a serious bug with the vendor of whatever distribution you're running on this box.

David,

I will comply and repost the oops.

Jeff

Quoted 3 lines

--
dwmw2