Bug #1661

panic on password entry mount smb filesystem

Added by vsrinivas over 11 years ago. Updated about 1 month ago.

In Progress
VFS subsystem
Target version:
Start date:
Due date:
% Done:


Estimated time:



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.

  1. mount_smbfs -I /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_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,




Updated by vsrinivas over 11 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?)



Updated by dillon over 11 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=

Hmm.  Looks like the thread has a NULL td_ucred.  My guess is that
smbfs is making the connection itself from a maintainance kernel
Try this patch.
Matthew Dillon

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)
if ((pr = td->td_ucred->cr_prison) NULL)


Updated by tuxillo over 6 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



Updated by notapipe almost 5 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:
dscheck(vn2): b_count 2 is not on a sector boundary (ssize 512)
Stopped at [...]


Updated by tuxillo about 1 month ago

  • Target version changed from 4.2 to 6.0

Also available in: Atom PDF