Bug #1661
openpanic on password entry mount smb filesystem
0%
Description
Hi,
When attempting to mount an SMB filesystem, I get a 'Fatal trap 12: page fault
while in kernel mode' after the password is requested by mount_smbfs. Tested on
a daily snapshot from 1/23/2010.
# mount_smbfs -I 10.0.2.4 //guest@10.0.2.4/data /mnt
With a 1/23/2010 GENERIC kernel, the backtrace:
prison_remote_ip(c17131d0,cc759cd0) at prison_remote_ip+0x1b tcp_usr_connect(c16b5f00,cc759cd0,c17131d0,0,ca2c2d64) at tcp_usr_connect+0x8f netmsg_pru_connect(cc759c28,c06d4ee0,c06d5278,ca3c3d84,c03c7e5f) at netmsg_pru_connect+0x13 netmsg_service(cc759c28,c06d4ee0,ff800000) at netmsg_service+0x58 tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x1d lwkt_exit() at lwkt_exit
I can upload a coredump and vmcore if needed,
Thanks,
--vs
Updated by vsrinivas almost 15 years ago
(kgdb) bt #0 _get_mycpu (di=0xc069af40) at ./machine/thread.h:83 #1 md_dumpsys (di=0xc069af40) at /usr/src/sys/platform/pc32/i386/dump_machdep.c:264 #2 0xc031db66 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:838 #3 0xc031e0e1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387 #4 0xc031e202 in panic (fmt=0xc058779e "from debugger") at /usr/src/sys/kern/kern_shutdown.c:744 #5 0xc0172685 in db_panic (addr=-1070527193, have_addr=0, count=-1, modif=0xca29abb0 "") at /usr/src/sys/ddb/db_command.c:448 #6 0xc0172cfa in db_command () at /usr/src/sys/ddb/db_command.c:344 #7 db_command_loop () at /usr/src/sys/ddb/db_command.c:470 #8 0xc01752c8 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 #9 0xc0524da8 in kdb_trap (type=12, code=0, regs=0xca29accc) at /usr/src/sys/platform/pc32/i386/db_interface.c:152 #10 0xc0536790 in trap_fatal (frame=0xca29accc, eva=<value optimized out>) at /usr/src/sys/platform/pc32/i386/trap.c:1129 #11 0xc0536ab7 in trap (frame=0xca29accc) at /usr/src/sys/platform/pc32/i386/trap.c:413 #12 0xc0526187 in calltrap () at /usr/src/sys/platform/pc32/i386/exception.s:785 #13 0xc0310d27 in prison_remote_ip (td=0x0, ip=0xcc753cd0) at /usr/src/sys/kern/kern_jail.c:404 #14 0xc03cd4a2 in tcp_usr_connect (so=0xc16b5f00, nam=0xcc753cd0, td=0xc17131d0) at /usr/src/sys/netinet/tcp_usrreq.c:474 #15 0xc0351f04 in netmsg_pru_connect (msg=0xcc753c28) at /usr/src/sys/kern/uipc_msg.c:486 #16 0xc0395fe8 in netmsg_service (msg=0xcc753c28, mpsafe_mode=1, mplocked=0) at /usr/src/sys/net/netisr.c:310 #17 0xc03c7e5f in tcpmsg_service_loop (dummy=0x0) at /usr/src/sys/netinet/tcp_subr.c:410 #18 0xc0326251 in lwkt_deschedule_self (td=Cannot access memory at address 0x8 ) at /usr/src/sys/kern/lwkt_thread.c:243 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (kgdb)
Updated by dillon almost 15 years ago
:#13 0xc0310d27 in prison_remote_ip (td=3D0x0, ip=3D0xcc753cd0)
: at /usr/src/sys/kern/kern_jail.c:404
:#14 0xc03cd4a2 in tcp_usr_connect (so=3D0xc16b5f00, nam=3D0xcc753cd0,=20
: td=3D0xc17131d0) at /usr/src/sys/netinet/tcp_usrreq.c:474
:#15 0xc0351f04 in netmsg_pru_connect (msg=3D0xcc753c28)
: at /usr/src/sys/kern/uipc_msg.c:486
:#16 0xc0395fe8 in netmsg_service (msg=3D0xcc753c28, mpsafe_mode=3D1, mplock=
:ed=3D0)
:...
Hmm. Looks like the thread has a NULL td_ucred. My guess is that smbfs is making the connection itself from a maintainance kernel thread.
Try this patch.
-Matt
diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c index f867b9d..6c61867 100644 --- a/sys/kern/kern_jail.c +++ b/sys/kern/kern_jail.c @@ -399,7 +399,7 @@ prison_remote_ip(struct thread *td, struct sockaddr *ip) struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)ip; struct prison *pr; - if (td == NULL || td->td_proc == NULL) + if (td == NULL || td->td_proc == NULL || td->td_ucred == NULL) return(1); if ((pr = td->td_ucred->cr_prison) == NULL) return(1);
Updated by tuxillo almost 10 years ago
- Description updated (diff)
- Category set to VFS subsystem
- Status changed from New to In Progress
- Assignee deleted (
0) - Target version set to 4.2
Grab
Updated by notapipe over 8 years ago
I confirm this bug under DragonFly 4.6.0, can be reproduced reliably
Fatal trap 9: general protection fault while in kernel mode
[...]
CPU3 stopping CPUs:
stopped
dscheck(vn2): b_count 2 is not on a sector boundary (ssize 512)
Stopped at [...]