Bug #1016

mount_cd9660 crashes the kernel

Added by voroskoi almost 6 years ago. Updated almost 6 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

DragonFly 1.13-DEVELOPMENT #1: Mon May 19 23:26:51 CEST 2008 crashes on a simple
mount_cd9660 /dev/cd0 /mnt/cdrom.

The last commit in this kernel is:
http://repo.or.cz/w/dragonfly.git?a=commit;h=a13a97e518b44d453d9329dbb0909b27c730803d

Here is the error message:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02d3e15
stack pointer = 0x10:0xca3ed6c8
frame pointer = 0x10:0xca3ed744
code segment = base 0x0, limet 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = intercept enabled, resume, IOPL = 0
current process = 7660 (mount_cd9660)
current thread = pri 10

kernel: type 12 trap, code 0
Stopped at dsioctl+0x39: movl 0x8(%esi),%ebx
db> trace
dsioctl(snip) at dsioctl+0x39
cdcheckmedia(snip) at cdcheckmedia+0x246
cdopen(snip) at cdopen+0xd0
dev_dopen(snip) at dev_dopen+0x2f
diskopen(snip) at diskopen+0x7d
dev_dopen(snip) at dev_dopen+0x2f
spec_open(snip) at spec_open+0x18b
spec_vnoperate(snip) at spec_vnoperate+0x11
ufs_vnoperatespec(snip) at ufs_vnoperatespec+0x11
vop_open(snip) at vop_open+0x32
vn_open(snip) at vn_open+0x326
kern_open(snip) at kern_open+0x84
sys_open(snip) at sys_open+0x32
syscall2(snip) at syscall2+0x1ec
Xint0x80_syscall() at Xint0x80_syscall+0x36

I was only able to write it down to a piece of paper, hopefully i did not make
any typo. Also i was lazy to add the memory addresses too for the functions, let
me know if you miss them or anything else.

One more thing: using /dev/acd0 works fine.

History

#1 Updated by dillon almost 6 years ago

:New submission from VOROSKOI Andras <>:
:
:DragonFly 1.13-DEVELOPMENT #1: Mon May 19 23:26:51 CEST 2008 crashes on a s=
:imple
:mount_cd9660 /dev/cd0 /mnt/cdrom.
:
:The last commit in this kernel is:
:http://repo.or.cz/w/dragonfly.git?a=3Dcommit;h=3Da13a97e518b44d453d9329dbb0=
:909b27c730803d
:
:Here is the error message:
:
:Fatal trap 12: page fault while in kernel mode
:fault virtual address =3D 0x8
:fault code =3D supervisor read, page not present
:instruction pointer =3D 0x8:0xc02d3e15
:stack pointer =3D 0x10:0xca3ed6c8
:frame pointer =3D 0x10:0xca3ed744
:code segment =3D base 0x0, limet 0xfffff, type 0x1b
: =3D DPL 0, pres 1, def32 1, gran 1
:processor eflags =3D intercept enabled, resume, IOPL =3D 0
:current process =3D 7660 (mount_cd9660)
:current thread =3D pri 10
:
:kernel: type 12 trap, code 0
:Stopped at dsioctl+0x39: movl 0x8(%esi),%ebx
:db> trace
:dsioctl(snip) at dsioctl+0x39
:cdcheckmedia(snip) at cdcheckmedia+0x246
:cdopen(snip) at cdopen+0xd0
:dev_dopen(snip) at dev_dopen+0x2f
:diskopen(snip) at diskopen+0x7d
:...
:sys_open(snip) at sys_open+0x32
:syscall2(snip) at syscall2+0x1ec
:Xint0x80_syscall() at Xint0x80_syscall+0x36
:
:I was only able to write it down to a piece of paper, hopefully i did not m=
:ake
:any typo. Also i was lazy to add the memory addresses too for the functions=
:, let
:me know if you miss them or anything else.
:
:One more thing: using /dev/acd0 works fine.

That's excellent information. I haven't been able to reproduce the
problem, though, I seem to be able to mount from /dev/cd0 ok. I have
some suspicions, though, considering where it is panicing.

What kind of CD did you have in the drive? A DragonFly CD or something
else? Did you perform any other actions prior to doing the
mount_cd9660? Such as mounting it (or trying to mount it) via some
other path?

Can you reproduce the problem and perhaps get a kernel core dump?

-Matt

#2 Updated by voroskoi almost 6 years ago

No, i can crash it right after logging in.
It's a simple data cd with some mp3, but i can reproduce it with my
dfly-1.12.2 cd too. (Both cd is rewritable.)

Yes, it's always reproductable. You can find the core dump here:
http://frugalware.org/~voroskoi/dfly/dfly-mount_cd9660-coredump.tar.bz2

#3 Updated by wa1ter almost 6 years ago

> ...

Hi Andras. I can't help you with your crash but the 'repo.org.cz' caught my attention.
Simon, are you updating that git repository regularly now? If so I'll start using it
myself.

#4 Updated by dillon almost 6 years ago

The crash dump is really helpful. I have reproduced it. What is
happening is that cdcheckmedia() is being called before the slice
table is getting set up. I think adding some simple conditionals to
those dsioctl()'s will solve the problem.

I should have a fix for the mount_cd9660 issue committed today.

-Matt
Matthew Dillon
<>

#5 Updated by dillon almost 6 years ago

More precisely, the commit on the 18th updating the CAM code is setting
CD_FLAG_OPEN early, causing dsioctl() to improperly be called before the
slice table has been installed.

-Matt
Matthew Dillon
<>

#6 Updated by dillon almost 6 years ago

Bug in CAM, fix committed.

Also available in: Atom PDF